Automated SSL certificate installers

ABSTRACT

Disclosed herein are several digital certificate discovery and management systems. Detailed information on various example embodiments of the inventions are provided in the Detailed Description below, and the inventions are defined by the appended claims.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims the benefit of U.S. Provisional Application Ser.No. 60/495,864 filed Aug. 15, 2003 and U.S. Provisional Application Ser.No. 60/586,429 filed Jul. 8, 2004, both of which are hereby incorporatedby reference in their entirety.

BACKGROUND

The claimed inventions relate generally to management of public keyinfrastructure server networks, and more particularly to systems thatcan automate the installation, renewal, detection or management ofpublic key infrastructure digital certificates in a secure networksystem.

BRIEF SUMMARY

Disclosed herein are several digital certificate discovery andmanagement systems. Detailed information on various example embodimentsof the inventions are provided in the Detailed Description below, andthe inventions are defined by the appended claims.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 depicts conceptual elements of asymmetric cryptography.

FIG. 2 shows conceptual elements of a process useful to secure dataagainst unauthorized access.

FIG. 3 shows conceptual elements of a process useful to digitally signdata.

FIGS. 4A, 4B, 4C and 4D depict a method of establishing securecommunications between a client and a server over a network.

FIG. 5 depicts components of a certificate management system providingcertificate management functions.

FIG. 6 shows components of an integrated certificate management system.

FIG. 7 depicts a certificate management system whereby certificatemanagement is conducted from an external network location from anenterprise

FIG. 8 shows a simplified method of automatically receiving andinstalling signed certificates from certificate authorities.

FIG. 9 depicts a simplified certificate renewal process.

FIG. 10 shows an automated simplified method of monitoring and renewingcertificates.

FIG. 11 shows conceptual elements of a certificate authority abstractor.

FIG. 12 illustrates a procedure for discovering network certificates.

FIG. 13 shows an exemplary process permitting a server device toauthenticate a client component associated with a user, account, orother association.

FIG. 14 shows a system useful for managing client certificates andproviding network services.

FIG. 15 shows a representative home page for an exemplary certificatemanager.

FIG. 16 depicts a representation of a manage certificates screen for anexemplary certificate manager.

FIG. 17 shows a representation of a manage servers screen for anexemplary certificate manager.

FIG. 18 shows a sample screen for managing groups in an exemplarycertificate manager.

FIG. 19 shows a representative screen for the management of registeredusers in the exemplary certificate management system.

FIG. 20 shows a representative screen of an exemplary certificatemanager whereby network settings may be input.

FIG. 21 depicts a representative screen containing entries for customfields for managed certificates in an exemplary certificate managerinterface.

FIG. 22 depicts a representative screen by which the certificatedatabase settings may be maintained in an exemplary certificate managerinterface.

FIG. 23 shows a representative screen by which default certificateinformation may be configured in an exemplary certificate manager.

FIG. 24 shows an exemplary screen in which replicator settings mayoptionally be configured in an exemplary certificate manager.

FIG. 25 shows a screen for entering network discovery settings in anexemplary certificate manager.

FIG. 26 shows a screen for entering configuration of the intermediateroot certificate authority settings of an exemplary certificate manager.

FIG. 27 depicts a screen whereby the log archival settings may be set inan exemplary certificate manager.

FIG. 28 depicts a representative screen permitting the management ofcertificates discovered but not yet completed in an exemplarycertificate manager.

FIG. 29 depicts a screen for completing or removing discovered serverrecords to or from an exemplary certificate manager database.

FIG. 30 shows a screen whereby a report may be selected from a list ofavailable reports, generated and printed in an exemplary certificatemanager interface.

FIG. 31 shows a historical report of intermediate root certificateauthority scans as generated by an exemplary certificate manager.

FIG. 32 depicts a view of an error log generated by an exemplarycertificate manager.

FIG. 33 depicts a view of an alert log generated by an exemplarycertificate manager.

FIG. 34 depicts a view of a user log generated by an exemplarycertificate manager.

FIG. 35 shows a view reporting all managed certificates in an exemplarycertificate manager interface.

FIG. 36 shows a view reporting all managed servers in an exemplarycertificate manager interface.

FIG. 37 shows a representative login screen for an exemplary certificatemanager.

FIG. 38 shows a representative screen for viewing the entries ofparticular users registered in an exemplary certificate manager.

FIG. 39 shows a representative screen for editing user entries in anexemplary certificate manager.

FIG. 40 shows a representative screen of a view of certificateinformation for an exemplary certificate manager.

FIG. 41 depicts a screen in which an existing certificate record may beedited for an exemplary certificate manager.

FIG. 42 depicts a screen for editing a group in an exemplary certificatemanager.

FIG. 43 shows a report of user actions generated by an exemplarycertificate manager.

FIG. 44 shows a report of changes to a certificate database generated byan exemplary certificate manager.

FIG. 45 shows a report of changes to a server database generated by anexemplary certificate manager.

FIG. 46 shows a manage servers screen in an exemplary certificatemanager.

FIG. 47 shows a screen whereby an administrator may enter informationabout a new certificate for an exemplary certificate manager.

FIG. 48 shows a screen for adding users to a group in an exemplarycertificate manager.

FIGS. 49, 50, 51, 52 and 53 depict exemplary screens generated in asecure client agent installation.

FIGS. 54 and 55 show login screens to an exemplary secure clientservice.

FIG. 56 shows a screen of an exemplary secure client service indicatingthe absence of a certificate on the client.

FIGS. 57 and 58 depict screens generated through the process ofregistering a client device with an exemplary secure client service.

FIG. 59 shows a screen for specifying authorized actions for a clientdevice in an exemplary secure client service.

FIG. 60 shows a client device configuration selection screen of anexemplary secure client service.

FIG. 61 shows a transaction report of an exemplary secure clientservice.

FIG. 62 shows a screen for specifying authorized actions for a clientdevice and a provider in an exemplary secure client service.

FIG. 63 shows a screen for entering user information in an exemplarysecure client service.

Reference will now be made in detail to systems and methods fordiscovering and managing digital certificates which may include somemore specific embodiments of the claimed inventions, examples of whichare illustrated in the accompanying drawings.

DETAILED DESCRIPTION

Public key infrastructure (PKI) has recently become widespread in use,particularly with the availability of public networks that provideaccess to confidential sources or sinks of information, for examplee-commerce over the Internet. PKI is utilized in many network systems toencrypt data transacted between a user on a client device and a server,and also to verify that the client is linked to an authentic serverdevice, particularly when the data transactions pass through anuncontrolled or insecure network portion.

Data encryption generally is of one of two types, which are symmetricand asymmetric cryptography. Speaking at a basic level, in symmetriccryptography a single key is shared by the encryptor and the decryptor,i.e. the encryption key can be used to decrypt data encrypted with thatkey. In FIG. 1, the basic concepts of asymmetric cryptography aredepicted. A key generation process 10 is used to generate a pair ofrelated keys, which are an encryption key 11 and a decryption key 12.The cryptographic algorithms are selected such that if either one of theencryption key 11 or decryption key 12 is known, the other key isdifficult to discover. The selection of appropriate algorithms and keysis well known in the art, and will not be expounded upon further here.Further in FIG. 1, the process of cryptography is shown. Data 13 is tobe sent to a receiver in a secure fashion. Encryption key 11 is appliedto data 13, producing encrypted data 14, perhaps in a single message ora group of packets. The encrypted data is sent to the receiver throughthe insecure network, thereby preventing access to the original data 13by undesirable parties. A receiver applies decryption key 12 to theencrypted data 14, producing the original and decrypted data 15. Becausethe keys needed to encrypt and decrypt are different, this type ofcryptography is called asymmetric.

In public key cryptography one of the keys may be made public, which mayserve to either to secure data from unauthorized access or digitallysign transmitted data. By digitally signing data, the receiver mayverify that the received data comes from a particular sender and thatthe data has arrived unmodified. Referring now to FIG. 2, concepts of aprocess useful to secure data against unauthorized access are depicted.In the process of FIG. 2, an asymmetric key pair is generatedbeforehand, which include encryption key 21 and decryption key 25.Encryption key 21 is made public, i.e. it is provided to others wishingto send encrypted data to a receiving party holding decryption key 25,which is held private by that receiving party. A sending party uses thepublic key 21 to encrypt secret data 20, producing encrypted data 22.Encrypted data is sent to the receiving party by way of a network link23, which might be insecure and/or subject to interception. The receivedencrypted data 24 is then applied to the private decryption key 25,producing decrypted data 26 identical to the original secret data 20. Inthis process, the security of the data relies on the difficulty ofproducing the decryption key 25 from the public encryption key 21 andthe inaccessibility of private key 35.

Referring now to FIG. 3, concepts of a process useful to digitally signdata are depicted. Data 30 is to be provided to a receiving party overin insecure network link 37, i.e. the sending and/or receiving partiesdo not control the link sufficiently to prevent a third party sendingdata to the receiver masquerading as the sending party. Data 30 is firstencrypted with a privately held encryption key 31, producing anencrypted form 32 of the original data. The encrypted data 32 is thensent to the receiving party 33 over an untrusted network link, whichmight be the same or a different link as the one used for transmission37. The received encrypted data 34 is then decrypted with the publicdecryption key 35, producing decrypted data 36. The decrypted data maythen be compared to the unencrypted data provided through transmission37, which may be considered to be from the sending party if the two datasets are identical. As in the procedure depicted in FIG. 2, thisprocedure relies on the difficult of producing the private encryptionkey from the public decryption key, making unlikely the prospect thatthe private key could ever be discovered and used by a malicious party.Also in this procedure, public key 35 is transferred through acontrolled process that permits the receiving party to know the originalsource party of that key.

In a variation of the procedure of FIG. 3, an additional step produces ahash value of the data to be signed 30. The hash function may be chosento produce a substantially unique value for variations of input data,i.e. the hash value will change for any change to the input data, evenminute changes. The hash function may also be chosen to be substantiallynon-reversible, making extremely difficult the task of finding a changeddata set that produces the same hash value without exaustively iteratingthrough an extremely large number of possible changed data sets. In thatvariation, the hash value may be encrypted rather than the originaldata, and the verification includes the step of comparing the decryptedhash value against a hash value calculated from the received data to beverified. Of course, the sender and receiver must apply the same hashfunction.

Public key infrastructure (PKI) is the equipment and software requiredto practice public key cryptography for real-world applications, and maytake any number of forms. In one form, PKI may include a sender computerand a receiver computer, with software for encrypting and decryptingmessages, such as email messages. Often, PKI provides a facility for theretrieval of a public key from the data sender or the intendedrecipient, permitting encrypted communication without the need ofphysical public key transfers. In another PKI form, public keys areprovided by way of certificates. A PKI certificate is a data structurethat provides a public key to others. PKI certificates may be madeavailable by way of network servers to others with access to thatnetwork, thus providing an efficient way of distributing public keys.

In a commonly used PKI, certificates also include a signature to verifythe source of the certificate. Again, PKI keys are provided in pairs,one being held private and the other distributed publicly. The recipientof a public key may communicate with the holder of the correspondingpublic key in a secure fashion, but if the recipient obtained the publickey over a network he may not know what the source of that public keyis. It is therefore possible, in that circumstance, for a third party totrick or “spoof” the recipient party into holding communications withhim, if he can provide a substitute certificate to the recipient partyand if the third party's communications are sufficiently authentic tocomplete the deception. In a related technique of interception, a thirdparty may form an encrypted communications link with a destinationserver, provide a substitute certificate to a recipient, and masqueradeas the destination server by passing data between the recipient partyand the destination server. The third party may then view all trafficbetween the recipient and the destination server unencrypted. Thistechnique is often referred to as a “man in the middle attack”, and canbe a serious problem for many entities, such as banks or on-line stores,wishing to correspond with customers, employees and others over publicand/or uncontrolled networks.

To solve this problem a number of Certificate Authorities (CAs), forexample Verisign and Entrust, have created services for authenticatingcertificates. These entities hold themselves out as entities of trust,providing certificate signing services for certificate verification. Theoperation of a CA is generally as follows. First, a CA produces a set ofasymmetric key pairs, and therefrom a set of root certificates. Theprivate keys are secretly held by the CA, while the root certificatescontaining public keys are provided to others through controlleddistribution. These root certificates are made widely available to thepublic, for example in the distribution of web browsers, operatingsystems or other software. Next, a CA receives unsigned certificates inCertificate Signing Requests (CSRs), which contain sufficientinformation to produce a signed certificate and optionally to verify thesource of the individual CSRs. For individual CSRs, the CA may attemptto validate the CSR as coming from a known party, for example throughthe use of a password or other confidential information from thecustomer. Signed certificates are produced by choosing a rootcertificate, signing the certificate with the private key of the chosenroot certificate, including identification of the root certificate withthe signed certificate and returning the signed certificate to therequesting party.

A standard certificate specification, referred to as X509 has beenestablished to provide a common readable certificate format for publiclyaccessible utilities. This format will be recognized by those ofordinary skill in the art, and will be only briefly commented herein.The X509 format provides an example of a usable certificate format,noteworthy format items being a version number (the version of the X509standard being used), a public key, a signature value, a denotation ofthe signature algorithm used, a period of validity, and an issueridentification among other format items. Although this format has seenrecent widespread use, especially in https and secure shelltechnologies, other formats may be used with equally good results.

A client receiving a certificate from a server may verify a signedcertificate by doing the following. First the client may review thecertificate to see what certificate was used for signing (i.e. a parentcertificate). If the parent certificate is recorded at the client'slocation, it may locate it and extract the public key. If the parentcertificate is not known to the client, the client may request theparent certificate from an accessible server. Upon receipt of the parentcertificate, the client may extract the public key. Having the publickey, the client may then verify the signing of the child certificate. Ifthe parent certificate was obtained remotely, the client may continue byverifying the signing of the parent certificate. That procedure maycontinue through a chain of certificates until reaching a knowncertificate, or reaching an unsigned or unavailable certificate. Shouldthe process end without reaching a known certificate, the client mayconsider the child certificate (and other certificates in the chain) tobe untrustworthy, and may provide a warning to a user.

Referring now to FIGS. 4A through 4D, a method of establishing securecommunications between a client and a server over a network is depicted.In FIG. 4A, a negotiation takes place between the client and the server.This involves client 40 sending a request to server 41 to initiatenegotiation. If multiple communication modes are available, i.e. if morethan one cryptographic algorithm is available for use, one of client 40or server 41 will chose a mode. Following negotiation, sever 41transmits a certificate to client 40 containing a public key, as shownin FIG. 4B. The client may verify the server's certificate, if desired.In response, client 40 chooses a secret key to be shared with server 41.The choosing of secret key may be performed so as to avoid use of keyspreviously used, and may also be chosen to avoid predictability, forexample by choosing a key from a random number generator. Client 40,using the server's public key, then encodes the secret key in a messagesubsequently sent to server 40, as in FIG. 4C. Secure communication maythen be conducted using a symmetric encryption technique using theshared secret key between client 40 and server 41, as in FIG. 4D.

Certificate Life Cycle

A certificate is normally used for a limited amount of time for a numberof reasons. Certificates are priced according to the length of thevalidity period. This pricing is not merely for profit making, as thereis an expense associated with maintaining the certificate authorityinfrastructure, i.e. maintaining servers that can validate issuedcertificates. A service provider may therefore not wish to purchase acertificate lasting a lengthy period of time, particularly if thecertificate is to be used in a test or uncertain venture. Additionally,the longer a certificate is in existence and/or service, the more likelythe private key will be discovered. An attack on a PKI key pair isthought to best be performed by an exhaustive search for a private keythat decrypts intercepted encrypted data. Test searches are known tohave been successfully conducted using supercomputer clusters in aperiod of months against keys of typical size. A longer period of usemeans that, first, an attacker will have more time to perform the searchand, second, an attacker may have more intercepted data to validate theresulting possible private keys that are found. Additionally,certificate validity periods may be especially important whenconsidering insiders, administrators and other internal employees havingaccess to SSL servers may have additional opportunity to compromiseprivate keys through their administrative access.

Having a limited service life of certificates requires interventionand/or certificate renewal upon the expiration of the validity of thosecertificates. Recent experience with PKI enterprises has shown thatcertificates are too often not properly renewed before expiring. Shoulda certificate expire unnoticed, the associated service may becomeunavailable. Should the PKI continue to operate, users are likely toexperience warning messages, which may cause those users to avoid usingthe service. The service may further be subjected to an increasedprobability of a compromise, with devastating consequences. Should acertificate renewal failure occur for a large enterprise, for example alarge Internet seller or lender, significant revenues may be lost.

The causes of certificate renewal are many in number, a few of which arenoted here. An entity may fail to note the expiration of a certificate.The certificate authority may send a reminder by postal or e-mail, withsome chance of mis-delivery. For example, the certificate authority mayhave a postal or e-mail address that has changed due to the entitymoving or changing its domain name. If the entity is located overseas,there is also an increased opportunity for the notification to sufferdelay. If the entity maintains a manual certificate database, there is achance for an erroneous or missing entry. Furthermore, a notificationmay be missed by an administrator, which individual may be busy, onvacation, incompetent or terminated. For larger organizations, there maybe several administrators multiplying that problem. Additionally, theprocess of renewing certificates has been a manual process, and subjectto typos and other technical errors.

Service entities have operated for months and years ignorant of thedangers of expiring certificates. When the problem is discovered, it maybe too late to recover without downtime of the enterprise. Should anentity face such a crisis, there are presently no tools for surveyingthe certificates in service. The administrators may then find themselvesvisiting every server of the enterprise, creating a compilation of thecertificates installed and the relevant expiration dates. Ascertificates are renewed, the administrators may update the compilationto get a handle on the schedule of certificate renewals. Again, this isa manual process and subject to human errors, which process puts anentity at risk of downtime and loss of income or services to clients orcustomers. For very large enterprises having thousands of certificates,the certificate renewal workload may require the attention of severaladministrators, which increases the expense of the operation.

Disclosed below are a number of systems and methods useful inenvironments of certificate management. Some of the disclosed systemsserve a single function related to certificates. Others combine severalof those functions into more comprehensive systems. Of the manypotential combinations most, if not all, are useful, and thereforecombinations may be chosen for particular circumstances of certificatemanagement.

Individual disclosures herein may take the form of computer systemsperforming functions by software, software executable by a computingsystem, or a group of functions performable by a computing or softwaresystem to achieve various functions, or other forms. The reader shouldrecognize that wherever disclosure is made of one of these types below,the others will also be made apparent.

Certificate Inventorying Systems

Certain of the systems disclosed herein relate to discovering andinventorying certificates installed to a set of network servers. In afirst exemplary system, a database is maintained containing recordsrelating to inventoried certificates. Each record identifies acertificate and a server to which the certificate resides or isinstalled. For each certificate, an expiration date or time may also benoted, by which the expiring of certificates may be noticed. Likewise,an expiration period may also be noted. Notation may also be made incertificate records for an issuing certificate authority. Other items ofdata relating to certificates may also be tracked, for example thecommon name, organization, an identification of a responsibleindividual, the strength of the encryption keys, etc. Expiredcertificates may also be tracked in a database, if desired.

Such a certificate database may be maintained using common file formats,for example CSV or dBase formats without becoming unwieldy, as thenumber of certificates tracked in a typical organization will berelatively small. A certificate database might also be maintained in arelational database server, which may provide additional search, remoteaccess, encryption and other helpful database functions. Access to acertificate database may be controlled. In the exemplary system accessto the database is provided only to authenticated persons and/orapplications. A certificate database may take many other forms asdesired, the details of which are not particularly important.

Entries and modifications to the certificate database may be performedmanually, or applications may be provided for managing certificateentries in the database through the use of graphical user interfaces,web interfaces, or many other techniques. Entries may also be made by acertificate scanner, which will be described shortly. A database ofrelated servers, i.e. servers on which certificates reside or serverswithin a defined network, may also be kept. Such a server database maybe kept separately from a certificate database, or may be integrated inthe same database, file or data structures.

A certificate database may be maintained to provide informationregarding the state of certificates in a network at given times. Thismay be used, in one example, by an administrator to identifycertificates due to expire, or certificates that have expired. Inanother use, certificates may be related to servers to identify unusedor duplicate certificates. In yet another use, a survey may be conductedusing the database to identify certificate authorities being used, aschedule of certificate renewals, encryption strengths, certificates ona particular domain, or other reviews useful to manage a secure networksystem.

A certificate inventorying system may additionally include a certificatediscovery tool for locating certificates in a chosen network. Thediscovery tool may receive as input a network address range, which inone example includes an IP address and subnet mask for an 'P protocolnetwork. In another example, a list of IP address ranges are given. Forother network types, a network name, SSID name or other identifier maybe used in accordance with the network's addressing standards.

Referring now to FIG. 12, a procedure for discovering networkcertificates is described. First, in step 1202, a network address rangeis input and received by the discovering system. In this example, anempty database is created in step 1204 for holding the resultingcertificate information. The procedure iterates through the addressrange in step 1206, which includes a process illustrated in furtherdetail in steps 1212 through 1222. Alternatively, in some networkprotocols a search function is available which may report devicesregistered on the network. In that case, the procedure may iterate overthe registered devices. In step 1208, once the address range has beenscanned, the resulting database may be stored, or alternatively it maybe merged with an existing database, particularly if the results of aprior scan are available. Alternatively, an existing certificatedatabase might be directly modified, adding newly discoveredcertificates and optionally removing certificates no longer inexistence.

At each address iterated through, steps 1212 through 1222 are executedin a subroutine. First, an attempt to connect with the device at thecurrently iterated device is made over the network, as in step 1212. Ifthe attempt is unsuccessful, the subroutine may exit, as in step 1214.Should a successful connection be made, an attempt to retrieve acertificate will be made, as in step 1216. If a certificate is notavailable, decision 1218 causes an exit of the subroutine, as there isno certificate information to record. Otherwise, the subroutine parses areceived certificate for items of interest, as in step 1220. The itemsof interest may be any information related to the received certificate,but might be a certificate identifier, an expiration date, in oneexample. The parsed information may then be recorded to an entry in thescan database, as in step 1222, optionally with other relatedinformation such as the current network address, server type, or otherinformation.

The procedure shown in FIG. 12 shows a single attempt to connect with anetwork device. This attempt might be, for example, an attempt toestablish an SSL handshake over IP port 443, which is the port commonlyused for the HTIPS secure connection service. Through the course of thehandshake, the SSL certificate is provided to the connector, which isone way it may be retrieved. Other ports or methods may be used toattempt the connection and retrieval of certificates. In an alternatemethod, an attempt may be made to mount a device's filesystem (or aportion thereof) through an NFS or SMB connection. Followingestablishment of a connection, a search may be conducted through theexported file system to locate probable certificates, which can beverified by attempting a parsing of the suspected file. The location acertificate is found provides clues as to what application is using it,if any. A similar and further alternate method attempts to establish asecure shell or telnet connection using a set of commonly used usernamesand passwords. In yet another alternate method, an attempt may be madeto access an administrator interface provided by a web server or otherapplication providing access to certificates. Other methods of obtainingcertificates may be available, depending on the devices attached to thenetwork, which may be incorporated to provide improved scanningcoverage.

A discovery system may provide for log production of the discoveryprocess. The log might show any of items such as: addresses scanned,ports scanned, failed and/or successful connection attempts, addresseswith no response, certificate identifiers and other certificateinformation, server software types and version numbers, modifications toan existing certificate database, and many other items as desired. Adiscovery system may additionally combine the results of scans conductedat different times, which may be useful to catch servers which may havebeen inoperative at a particular time. Although the procedure of FIG. 12attempts only a single connection, the procedure may be modified toperform two or more connection/retrieval techniques. In that case, thelog may additionally reflect the techniques used as well astechnique-specific information.

The result of a discovery process may be a database providing an auditof certificate conditions on a network, which may be utilized byadministrators in certificate maintenance activities. A discoveryprocess may be conducted manually, by software, by a network appliance,or any other object of execution as desired. In one example, a discoveryprocess is conducted by a software application installed to a hostcomputer on a network. In that example, the software may be provided ona disk or other medium, and may be packaged with other software andinstructional items as a stand-alone software product. In anotherexample, the discovery process may be conducted by a dedicated networkappliance, which may provide a user interface through the HTP or HTTPSprotocols, or by other user interface type. In that example, thedatabase may reside on the appliance, or may be created or deposited toanother computing device, which might be an RDBMS or NAS device. Adatabase or log might also be sent in an e-mail message, or might besent to a printing device for a hardcopy by the appliance. In a furtherexample, described below, the appliance includes other functions relatedto certificate management, including software for renewing andinstalling certificates. Many other variations are possible and may befashioned in accordance with the desires and preferences of theimplementer.

A certificate discovery system may detect certificates that are notused, and may report those unused certificates to an administrator.Discovered certificates may also be archived, avoiding the need toprovisioning of new certificates should a server crash or otherwisebecome inoperable. If private keys are also discovered, those can alsobe archived if desired. Other systems as disclosed below may also reportunused certificates or archive certificates as desired, managed orotherwise.

Certificate Installation/Renewal Systems

Other systems may be fashioned to assist with the installation andrenewal of PKI certificates. Those systems may assist with the issuanceof a certificate and may perform steps to install certificates toappropriate server destinations and other PKI devices.

Referring now to FIG. 8, a simplified method of automatically receivingand installing signed certificates from certificate authorities isdepicted. First, an automated system receives a notification from acertificate authority, as in step 81. This may take place by email, asdescribed below, through polling on a web interface, or othernotification facilities. Alternatively, an alarm or timeout may initiatethe process rather than a notification, which may be set prior to orabout the time of expiration, or alternately may be set to according toa predefined period after certificate issuance. Optionally, other eventsmay trigger the notification of a certificate due to be renewed, forexample according to risk profiles or reports from other systems, suchas an intrusion detection system, that a server has been compromised.Upon reception of a notification, the system tests whether thenotification concerns a new certificate, as in step 82. If a newcertificate is referred to or included in the notification message, thecertificate is extracted in step 83 from wherever it is located. It maynot be apparent which server is to be the target of the new certificateinstallation, and therefore a destination server is identified in step84. The certificate may then be installed to the destination server, asin step 85. The process may repeat with the reception of additionalnotifications and may be executed as frequently as needed.

The installation of newly issued certificates may proceed as follows.First, it may be necessary to request and receive a certificate from acertificate authority, if it is not desired to use anintemally-generated certificate. A common method of certificate receiptis by e-mail received at the same computer from which a certificatesigning request was submitted. For a signed certificate received from acertificate authority, it may be necessary to determine a destinationserver for the certificate upon receipt. For example, if the certificateis a renewed certificate for a certificate about to expire, it may bedesirable to install the certificate to the server storing the expiringcertificate. Alternatively, a certificate may under some circumstancesbe held prior to installation. In one situation, it may be desirable torequest renewed certificates well in advance of the expiration of oldcertificates. The old certificate is, in that situation, allowed to agebefore installing the renewal certificate. In another situation, acollection of servers may serve the same network address, throughnetwork address translation or other techniques. A collection of renewalcertificates may, in that situation, be maintained in a store untilneeded, at which time the oldest renewal certificate may be installed toservers having certificates about to expire.

Regardless of the situation, a fresh or renewal certificate isassociated to a destination network server at the time it is signed. Adestination network server is therefore identified as corresponding tothe received signed certificate. After a server is identified the servertype is determined, in order to choose the proper method ofinstallation. For example, if the server is serving web pages over theHTIPS protocol, there are a number of possible web server products thatmight be installed. For example, the Apache web server might dictatethat certificates be installed through a file placement to a specifieddirectory, a modification of particular configuration files (especiallyfor non-renewed certificates), and restarting of the web server daemons.In another example, an iPlanet web server might provide a webadministrator interface. In that circumstance the text of thecertificate might be cut and pasted from an email into a text entryfield, following which the web administrator installs the certificatetext in the correct location. It may also be necessary to restart thePKI application and/or computer to flush the old certificates out ofmemory. Installation scripts might be written to support a number of PKIplatforms, for example iPlanet, Apache, IIS, Netscape, Websphere in amultiplicity of versions.

In many if not most installation procedures, an authentication step willbe required to access the certificate store on the destination device.This may involve offering an administrator username and password, apassphrase, a certificate or other authorization object. Anauthorization object may be stored within or accessible to theinstallation system prior to the installation activities.

The installation system has access to installation instructions whichconstitute a set of installation steps for installing certificates toparticular server types. These installation instructions may take manyforms, the content of which will depend on the type of interface used toperform the installation steps.

In a first example, the installation instructions define a set of shellcommands. An exemplary set of shell commands for installing acertificate to an apache server might be: (1) log onto the destinationserver using an SSH connection and using a pre-stored username andpassword, (2) use the “cd” command to change the current directory tothe certificate directory store, i.e. “cd/etc/ssl/apache”, (3) removethe old certificate, i.e. “rm -f ./server.crt”, (4) install the newcertificate, i.e. “echo MIIDBTCCA . . . >server.crt”, (5) install thenew private key, i.e. “echo MIICXQ . . . >server.key”, (6) restart theweb server, i.e. “apachectl restart”, and (7) terminate the SSHconnection. Now, the directories given above may vary between operatingsystem distributions and even between installations if an administratorhas changed the directory configuration from the default. If it isdesired to support an expanded range of server configurations, it may bedesirable to examine the server configuration files. In the aboveexample, which assumes a default Apache 2.0.47 server installed to aLinux Mandrake 9.1 operating system, the location of the ssl certificateand key can be found using the commands “grepSSLCertificateFile/etc/httpd/conf.d/41_mod_ssl.default-vhost.conf” and“grepSSLCertificateKeyFile/etc/httpd/conf.d/41_mod_ssl.default-vhost.conf”,assuming that root access is available. Similar installationinstructions may be fashioned through a study of other server productsto be supported.

A second installation instructional example utilizes file transferprotocols to deposit the certificate and key to a destination server.This example includes the steps of (1) using the scp protocol totransfer the certificate to the server, i.e. “scp -B server.crt/etc/ssllserver.crt”, (2) use the scp protocol to transfer the privatekey to the server, i.e. “scp -B server.key /etc/ssl/server.crt”, and (3)notify the administrator that the server needs to be restarted, forexample by an e-mail message. Other file transfer protocols can be used,such as FTP or NFS, however it should be kept in mind that usinginsecure protocols over public networks may comprimise the security ofthe destination server.

A third example utilizes a web interface provided with the serverapplication. A web interface is sometimes provided with a web server orother server application, by which control of the operation of theserver may be commanded through a web browser. The web interface, ifenabled, is accessible typically at a default relative URL, which mightbe at a special IP port, directory, CGI or other executable web scriptor program. In this example, the instructions are configured for aprogram that acts as a web browser, sending input back to the server'sweb interface as if the input came from a person operating a browser.This exemplary set of instructions includes (1) a command to go to thelogin URL of the web interface, (2) submit a form to the web interfacecontaining an administrator username and password, (3) receiving theresulting web page, (4) a command to go to the certificate entry URL ofthe web interface, (5) submitting a second form to the web interfacecontaining the new certificate and key, (6) confirming the submission ofa new certificate and key in a third form, (7) a command to go to theweb interface page including a “restart server” button, and (8) sendinga fourth form containing a selection of the “restart server” button.

The third example might be implemented in any number of ways. Forexample, a PERL script to perform the steps might be written utilizingan http protocol library. In another example, a web scripting languageis utilized to provide a shortenend and simplified interaction script.Likewise, any number of scripting or programming languages may be usedto provide controlled interaction with a server's web interface.

In a fourth example, an agent may be pre-installed to the destinationserver. In that example the agent monitors some communication channelfor instructions to install certificates and keys. That communicationchannel might take several forms, such as a TCP/IP connection, an SMTPreceiver, an RPC interface, or the agent might periodically review aconfiguration file located on the destination server or at anotherlocation. Likewise XML web service interfaces, web interfaces, and othersecure and non-secure layers or custom protocols might also be used.That agent would include support for the server type such that incomingcertificates are properly deposited in the correct location. Such anagent may also include authentication measures to prevent unauthorizedagent activity. The agent may optionally also cause a restart of theserver application or a reboot of the server itself.

A certificate installation system might utilize one or several methodsof certificate installation. Such a system might incorporate a tableselecting an installation method and/or script to execute depending onthe server type, i.e. the server's operating system and serverapplications installed thereon.

In a fifth related installation, information is first retrieved toeffect contacting and install the certificate to the destination webserver, accelerator or other device, that information including at leastsome of the platform type, the operating system, a default protocol suchas telnet, SSH, HTTP, HTTPS, etc., the certificate text, the destinationserver's 'P address or hostname, a user name and password to log ontothe destination, a password for the certificate store, the certificatecommon name, and a port number to initiate contact with the destination.Next, the certificate text is formatted to be in X.506 base 64 encodedformat. The destination is then connected to using the port number, IPaddress and protocol specified. For certain server applications such asthe Apache web server, an IBM web server, an IPlanet server oraccelerator, the OpenSSL service is started. Next, the command“find/-name ssl.conf”, or a similar command, is executed to locate theSSL configuration file. The command “find/-name httpd.conf”, or asimilar command, is also executed to locate the server configurationfile. Next the certificate and key name are extracted from theconfiguration file using “grep SSLCertificateFile/” or a similarcommand. A new configuration file is then generated either including orreferencing the new certificate, and written to the destination server.If needed, the “make” command may be executed to roll out the updatedcertificate information to all server files. The connection is thenterminated and the server restarted.

Now in the above examples, a new private key is installed for every newcertificate. The use of several keys over a period of time tends toincrease the difficulty of discovering the keys, or at least may preventan attacker from discovering a key while it is in use. The use of newkeys is not strictly required, however, and an installation proceduremay install a new signed certificate containing an old public key, ifdesired.

Also in the above examples, no provision is made to reconfigure a serverapplication to support PKI operation. Any of the above examples may beexpanded to configure PKI supporting applications, for example bymodifying files or accessing a web interface. By reconfiguring a serverautomatically, a laborious process of configuring servers for SSL orHTTPS support may be avoided.

Provision may also be provided in the certificate installation systemfor approvals. Upon receipt of a certificate signed by a certificateauthority an administrator may be notified, for example by email. Thereceived certificate may be held pending approval by the administrator.The installation system may provide an approval interface, for exampleaccessible by a web browser, by which an administrator may authenticatehimself to the system and select certificates approved to be installed.The interface may additionally provide for bulk approvals, i.e.presentation and approval of a group of certificates in a singleapproval step. The interface may additionally present certificatessorted in order of expiration date or priority, providing for ease ofadministrator selection. Optionally, certificates may also be presentedin order of risk according to certificate risk profiles. Followingapproval, the certificates may be installed to the appropriate servers,for example using automated processes as suggested above.

An installation and renewal system may also include provisions formonitoring expiring certificates. In such a system, certificates may beenrolled in a certificate watch program. On a periodic basis, forexample daily, weekly or monthly, a certificate database is reviewed forcertificates expiring within a future period. Finding certificates inneed of renewal, a notification may be sent to an administrator, whichfor example might be by e-mail or by a display upon login at anadministrator interface. The administrator may then select certificatesto be renewed, upon which a process of certificate renewal may beinitiated as described below. Alternatively, the renewal system may beconfigured to initiate certificate renewal without approval, to preventlate certificate renewal should an administrator be unavailable toapprove. If more than one administrator is configured, the renewalsystem may contact other administrators if first administrators do nottimely respond to requests for approval.

In an alternate mode, a renewal system may scan the servers of a networkperiodically, as in the discovery processes discussed above, to detectcertificates due to expire within a future period. In that systemcertificates might not be enrolled, but rather servers might be enrolledin a server watch list. In another alternate mode, agents are installedto the servers being monitored. Each agent periodically reviews thecertificates for expiration, and may notify an administrator or acentral system of any certificates about to expire, for example byemail.

A manual certificate renewal process is typically initiated at theserver to which the certificate will be installed. The process beginsfirst by the generation of a public/private key pair. Now the key pairmight be generated externally to the server, but that method introducessome risk of compromise in that the private key could be discovered inthe process of moving it to the server. Following the generation of thekey pair, a certificate signing request (CSR) is generated, which isbasically a partially completed certificate in that it contains thepublic key and server identification, but is not otherwise associated toa certificate authority or a root certificate. Having a certificatesigning request, it may either be sent to a certificate authority or itmay be signed in-house. If a certificate is to be used externally, itshould either be signed by a certificate authority or by using anintermediate root certificate itself signed by a certificate authority.Certificates to be used for internal use only may be signed by aninternally generated root certificate, because those certificatesmaintained by an organization may be considered to be trusted. Thesigning process generates and attaches a signature to the certificate,which signature is generally an encrypted hash value generated from anunsigned certificate generated from the CSR information and from otherinformation, such as the location of the root certificate and thevalidity period, which is encoded by the private key corresponding to apublic key of a root certificate. The signed certificate is then readyfor installation to the server.

The following method may be useful to generate a certificate signingrequest remotely using shell commands through an SSH, Telnet or othershell connection. First, the information needed as input to generate thecertificate signing request is provided, including at least some of theprotocol to be used, an email address, an 'P address, the locality ofthe certificate including the country, state and city, the organizationname, a certificate store password, and a port number to initiate aconnection with the remote platform. Next, the remote shell is opened tothe remote platform, utilizing known usernames and passwords or otherauthentication means. A command is then executed to set the remoteplatform to configure mode, followed by a command to enter an SSLconfiguration utility. The certificate store is then remotely opened andthe default SSL certificate selected. Next, the current private key isremoved from the certificate store. A new private key, for example a1024 bit DES key, is generated and placed in the certificate store. Anew PEM file or PKCS file is then created using the newly createdprivate key. A further command is then sent to exit the SSLconfiguration utility. The “gencsr key” command is then used to create anew certificate signing request file with the city, state, country,organization namelunit, common name and email address provided in theearlier input or obtained from default set values. The output of the CSRtext between the string identifiers “- - - - BEGIN CERTIFICATEREQUEST - - - - ” and “- - - - END CERTIFICATE REQUEST - - - - ” maythen be captured and optionally placed in a database for storage untilneeded. Housekeeping activities and disconnection may follow the captureof the certificate signing request.

A simplified certificate renewal process is depicted in FIG. 9, whichmay be operated by a certificate renewing system. First, in step 91, asearch is made to detect expiring and/or expired certificates in amanaged server group. Following detection of expiring/expiredcertificates, a loop is started in step 92, which ends when there are nomore expiring/expired certificates that remain unprocessed. For eachdetected expiring/expired certificate steps 93 through 97 are performed.In step 94, the appropriate server (the server holding theexpiring/expired certificate) is commanded to generate a new CSR andoptionally a new key pair, as described above. The renewal systemreceives the generated CSR, as in step 95, and sends the CSR to aselected certificate authority 96 for signing. Optional step 97 may beperformed to maintain a record of what certificates have been processedfor renewal. Upon exit of the loop starting at step 92, an alarm is setin step 98 to pause the execution for a period of time to avoidunnecessary processing. A certificate installation process may beconducted apart from this method and system in any way desired.

The public/private key pair may be generated off the destination server,particularly if the server does not include software to generate the keypair (many operating systems include a well-known product calledopenssl). If that is done, it may be desirable to ensure the networkbetween the generating computer and the destination is secure to avoidprivate key discovery.

The submitting a certificate signing request to a certificate authorityis typically performed through a network connection over the Internet.The certificate authority (CA) presents an interface, for example in aweb browser, in which an administrator may enter the CSR and otherinformation related to the request, such as the requesting entity'sidentification, account number or a challenge phrase. If desired, the CAmay permit the use of default values, in which case it may be possibleto initiate a request by submitting only a CSR and identification of therequester. Upon receiving the CSR, the CA may take steps to verify theidentity of the requester so as to avoid others from impersonating aproper requester and receiving valid and/or trusted certificates. Aftera period of time, usually at least several hours but typically not morethan a few days, the CA issues the signed certificate. The issuingtypically takes the form of sending the issued certificate to theadministrator in an e-mail message, although other transference methodsmight be used equally well.

In other communications with certificate authorities, specializedprotocols may be used. One exemplary protocol called the XML KeyManagement Specification (XKMS), the specification of and description ofwhich is available from the World Wide Web Consortium, may be used as astarting point for a certificate signing request transmission protocol.Web interfaces suitable for human access may also be used through httpautomation tools. Screen scraping, data manipulation, key strokeautomation, mouse click simulation and other forms of automation can beused to interact with such a web interface. Direct socket communicationmight also'be used.

A certificate renewal system may include facilities for automatingcertificate signing, as will be presently described. As with certificateinstallation, certificate signing requests may be subject to approval.As expiring certificates are identified, they may be presented to anadministrator for renewal. If it is desired to continue use ofparticular certificates or servers, an administrator may select thosefor certificate renewal. Approved certificates may be reviewed andparsed for informational items to be recycled, for example the serveridentity and the owning entity identity. A new certificate signingrequest is generated, either locally or remotely, for example at theserver to receive the certificate. If a CSR is generated locally, thegeneration uses the identity of the destination server. If desired, theCSR may then be sent to a CSR for signing. Alternatively, if a root orintermediate root certificate is to be used and is available locally,the renewal system may sign and issue the certificate.

If a CSR is submitted to a CA, a period of time will elapse beforeissuance of the corresponding signed certificate. It may therefore bedesirable to suspend the renewal process until the certificate arrives.For interacting with CAs that issue certificates by email, the systemmay monitor the incoming email messages. If desired, the system mayinclude a specialized SMfP module to receive emails, in the event thatan SMTP client isn't provided by the hosting operating system.Alternatively, an email filter may be applied to an existing SMTP systemto route messages from CAs to a renewal program. Regardless, the renewalsystem reviews the incoming email messages for issued certificates, andextracts them from the emails as needed. Alternatively, a CA may issuecertificate by download. In that event, the renewal system mayperiodically access the CA's website. Of course, if a certificate isissued locally, for example if a management system is configured to actas a CA, it is immediately available for installation. Once acertificate is received or otherwise available, it may be held pendingapproval or immediately installed as in the examples above.

The CA may have policy regarding the issuance of certificates, forexample declaring how an issued certificate may be used. A certificaterenewal system may be fashioned to be not only compatible with theprotocol requirements of CAs, but also with any policy requirements setforth.

In an exemplary certificate renewal method, challenge phrases used inthe submission of CSRs to CAs are stored in the renewal systemprivately, and may also be encrypted if further security is desired. Ifa CA requires the submission of an administrator certificate or otherobject to accompany the submission of a CSR, those objects may be storedat the renewal system and made accessible for transmission to the CA inaccordance with existing protocol. Internal CAs may also be used, i.e.certificate authorities controlled internally by a certificate usingentity, for example if public validation of certificates with trustedCAs is not required.

CSRs may also include custom fields, such as accounting codes, groupidentifiers, usage notations, and other information associated with aparticular issuing certificate. In one example, custom fields areincluded providing accounting codes that may be used to trackoperational expenses. In another example, usage notations are includedin CSRs to provide, encoded in the issuing certificates, instructionswhere to install the certificates. Many other uses of custom fields maybe used as desired, and may be facilitated by a renewal system.

A renewal system may also include access control for users and groups ofusers. The system may maintain a record of users authorized to view,change, renew and otherwise manage certificates. Authentication may bemade through the use of passwords, certificates or other identifyingobjects. Certificates may be assigned to be managed by a single user orseveral users. likewise, user groups may be configured to permitindividuals within the user group to manage certificates.

Throughout the renewal and/or installation progress a log may bemaintained by the system. The log may track activity at any level ofdetail desired, which might be in one example programmable. Entriesmight include logins, logouts, certificates approved for renewal,certificates approved for installation, which certificate authority wasused to renew particular certificates, which server a certificate wasinstalled to, which version of automation scripts were used and manyother possible events.

If it is desired to use intermediate root certificates to sign endcertificates, before creating a CSR an examination of availableintermediate root certificates may be performed to ensure the period ofvalidity of the end certificate is within the period of validity of aselected intermediate root certificate. Should an intermediate rootcertificate expire before the desired end certificate period ofvalidity, or the root certificate become valid after the start of theperiod of validity of the end certificate, an administrator may benotified of a problem. The administrator may choose to renew theintermediate root certificate, obtain a new intermediate rootcertificate with an appropriate validity period, defer the renewal of anend certificate, or choose to have a certificate to be renewed signed bya publicly available root certificate.

Likewise, an installation or renewal system may also handle theinstallation and renewal of intermediate root certificates. In thatsystem, it may be desirable to provide backup for intermediate rootcertificates and private keys from which those certificates have beengenerated, so as to prevent the loss of private keys necessitating theobtaining of new intermediate root certificates for issuing new endcertificates. A database may also be maintained including informationabout the relationship of intermediate root certificates and endcertificates issued from those root certificates. Other information maybe stored in such a database, such as the attributes of intermediateroot certificates, which devices contain those certificates, whatcertificate authorities issued those certificates, a history of endcertificates issued from intermediate root certificates, and otherrelated information.

Certificate Request Systems Supporting Multiple Certificate Authorities

A certificate renewal system or a certificate signing requesting systemmay make use of a certificate authority abstractor, which permitscertificate related interaction with two or more certificate authoritiesusing a common schema of operation. A number of certificate authoritiespresently make their services available, however each presents adifferent interface and procedures to administrators who wish to submitcertificate signing requests. Thus an administrator may be required tolearn the various web pages and/or software interfaces, functions,administrations, reporting and delivery systems of several certificateauthorities.

The conceptual elements of a certificate authority abstractor aredepicted in FIG. 11, which will now be disclosed A certificate authorityabstractor 115 receives a number of input items. First of all, a set ofscripts 114 a and 114 b are accessibly provided to abstractor 115, thosescripts containing programs or instructions sufficient to submit CSRs toa particular certificate authority. Those scripts may operate throughweb interfaces, specialized protocols such as XKMS, or othercommunications protocols according to the requirements of thecertificate authority for which the script is to interact. Additionallycertificate authority records, 113 a and 113 b, may be maintained toprovide default values for the scripts. For example, certificateauthority A may always request the organization name and account numberin the course of submitting a CSR, which may be conveniently set in arecord specially prepared for that certificate authority. Informationsufficient to identify the requesting entity to all supportedcertificate authorities may also be stored, in this example incertificate authority records 113 a and 113 b as an organization name,domain name and account number.

CA abstractor 115 also presents a uniform interface 119 for receivinginformation pertaining to the submission of an individual certificatesigning request 112. Interface 119 provides a uniform set of entries forat least the informational items required in a certificate signingrequest generally. These entries may provide for such items as a commoncertificate name, a period of validity, a locality identification, apublic key, user defined fields or other fields in many combinations.

In a first exemplary abstractor, the certificate request informationcontains only a certificate signing request generated externally, forexample at the server destined to receive a signed certificate. In asecond exemplary abstractor, the certificate request informationcontains information sufficient to complete a certificate signingrequest by the CA abstractor using a transferred public key. Many otherdata transference schemas can be implemented as desired with attentionto the details of any larger certificate automation system.

Abstractor 115 further receives a selection of a certificate authority116, which may occur one time through a default setting, or a CA choicemay be presented each time a certificate request information record 112is submitted. The selection of certificate authority determines whichscript will be executed and which certificate authority record will beexecuted. In some circumstances and as shown, the abstractor willinteract with one of certificate authorities 118 a or 118 b by way of anexternal network 117, which may be the Internet. Alternatively, if alocally maintained certificate authority is available, external network117 may be replaced with an internal network or other communicativeobjects. Once certificate authority records are received, certificaterequest records may be submitted to the abstractor, whereby the allrequired items by the selected certificate authority may be provided.The interaction by the script 114 may then communicate a request that inits totality constitutes a certificate signing request associated withthe requesting entity.

In an alternative abstractor the abstractor acts as a proxy applicationto the true certificate authorities. An administrator or system, forexample a certificate renewal system, may interact with the abstractoras if it were a true certificate authority, passing the sameinformational types using similar interfaces, as desired. Additionally,although interaction with two certificate authorities is shown, theconcepts disclosed above may be extended to support operation with anynumber of certificate authorities.

A certificate installation or renewal system may also perform averification operation to verify that a newly requested certificate hasbeen installed correctly and is available for use. In an exemplarymethod, the system may act as a client for the particular service forwhich the certificate is being used. For example, if a new certificateis for a web server supporting H'ITPS, the installation/renewal systemmay attempt a secure HTJPS connection with the destination server. Theverification may include checking for use of the new certificate andgeneral operation of the secure use. Notifications may be sent to anadministrator on success or failure, which may be after a timeout periodif verification does not immediately follow certificate installation. Inan exemplary system, alerts may be sent to more than one administrator,the system contacting further administrators if administratorspreviously notified haven't resolved a problem. That system may alsosubmit periodic messages, such as what certificates are due for renewalin the near future, for example a period of 14 days.

Presently, it is difficult for enterprises to switch between certificateauthorities, as the certificates under use may be expiring at differenttimes and the enterprise may wish to continue to use existingcertificate services paid for through the end of that term. In a manualsystem, as certificates expire an administrator is required to trackcertificates individually, renewing each certificate with the newauthority. This activity can be relatively expensive and is susceptibleto error.

In a certificate renewal system, a default certificate authority may beselected. That selected CA may then be used to renew certificates, bytransferring information from the old certificates into CSRs to the newselected CA. If desired, a renewal system might also be commanded toreplace all or a part of a set of managed certificates, swapping outcertificates one or more several undesirable certificate authoritieswith a selected certificate authority. In an exemplary renewal system a“migrate” function is provided permitting automatic transfer ofcertificates managed by unsupported certificate authorities to a defaultcertificate authority for which certificate requests are supported.

Systems for Managing Certificates in an Enterprise

A more complete system for managing certificates in an enterprise willinclude facilities not only for monitoring certificates, but also forrequesting renewed certificates and installing those certificates to theenterprise. Another simplified method depicted in FIG. 10 suggests theoperation of that system type. In that system, notifications are sentfrom certificate authorities, which are received by the system in step101. For each notification, a determination is made as to whether thenotice concerns a newly issued certificate, as in step 102. If thenotice concerns or includes a newly issued certificate, a processsimilar to that described for FIG. 8 is performed in steps 106-108 toextract the certificate and install it to an identified destinationserver. Another determination may be made in step 103 as to whether thecertificate authority is warning of an expiring certificate. If it is,an attempt to identify an enrolled server and/or certificatecorresponding to the notice is made in step 104. If the correspondingcertificate/server is enrolled, steps 109-111 are performed as in themethod described for FIG. 9, by which a new certificate signing requestis generated and sent to the appropriate certificate authority.

FIG. 5 depicts components of a certificate management system providingfunctions as described above for a single enterprise entity. Theenterprise includes a number of servers 53 a, 53 b, 53 c and 53 d forproviding services. Some of servers 53 a-d may provide services toclients 50 over an external network 51 by way of a gateway or router 52.Others of servers 53 a-d may provide services to clients 59 local to theenterprise entity. In the exemplary enterprise two accelerators 54 a and54 b are provided to assist in encrypted communications with clients 50or 59. At least one certificate authority (CA) is accessed to providenew and renewed certificates, which in this example are an internal CA60 and an external CA 61. Internal CA 60 is managed by the enterpriseentity and may be used to provide self-signed certificates, which may beuseful for internal secure communications. Internal CA 60 may alsoinclude an intermediate root certificate upon which individual servercertificates may be signed and issued, the intermediate certificatebeing made available for verification to parties encountering the issuedcertificates, for example over the external network 51. An external CA61 may also be utilized to issue digital certificates for securecommunications between client 50 and servers 53 a-d.

A scanner 57 may be provided to scan the network for certificates to bemanaged, which in this case would scan any or all of servers 53 a-d,accelerators 54 a and 54 b, and internal CA 60 if provided. Upon findingservers and certificates installed thereon, scanner 57 may provideresulting information to a database 58 containing informationidentifying certificates, expiration dates, and issuing CAs for thecertificates. An installer 56 may also be provided to automate theinstallation of new certificates on servers 53 a-d or accelerators 54 aand 54 b. Installer 56 may further automate the installation ofintermediate root certificates to internal CA 60, if desired. A renewer55 may be provided to monitor the expiration of certificates of whichinformation is stored in database 58 and may provide functions relatedto the renewal of expiring certificates. One function is to notify anadministrator of an expiring certificate. Another function is toinitiate the renewal of a certificate through the automated generationof a certificate signing request, optionally after administrativeapproval. Another renewal function is the delivery and/or installationof renewed certificates to servers. The system of FIG. 5 may be expandedto include other functions related to certificate management, forexample reporting services and provisions for access through anelectronic interface.

Referring now to FIG. 6, a similar system to that shown in FIG. 5 isdepicted, including a client 50, an external network 51, a gatewaydevice 52, servers 53 a-d, an internal client 59, and an externalcertificate authority 61. In the system of FIG. 6, the functions ofrenewer 55, installer 56, scanner 57, database server 58, and optionallyinternal CA 60 are combined in a single computing system called acertificate manager 62. In this example, the certificate manager 62 maybe “dropped in” to the enterprise system as a single piece of hardwareconnected to the enterprise's internal network, providing rapidcertificate management in the enterprise without unduly consuming spaceor computing resources.

In FIG. 7 a system is depicted whereby certificate management isconducted from an external network location from an enterprise. In thisexample the enterprise includes servers 53 a and 53 b, either or both ofwhich may include digital certificates for secure transactions with aclient 50. In this example certificate manager 70 is located outside ofthe enterprise network including servers 53 a and 53 b. To performcertificate management on servers 53 a and 53 b, certificate manager 70communicates electronically over the external network 51. The use ofsecure protocols for those communications may be desirable, particularlyif private keys are passed over the potentially insecure externalnetwork 51. An administrative client 71 b may access local certificatemanager 70 to perform administrative functions, for example configuringcertificate manager to service servers 53 a and 53 b. Certificatemanager 70 may also be made accessible to non-local administrativeclients 71 a, particularly if secure protocols are utilized in thataccess. An external certificate authority 61 may be accessed to providetrusted certificates to servers 53 a and 53 b, and also to certificatemanager 70 for secure administrative access.

The configuration of FIG. 7 may provide a service to enterprises wherebyadditional hardware is not required to be installed locally to theenterprise. In that example enterprises may subscribe to a service andfurther provide any necessary usernames and passwords for administratoraccess to the enterprise servers, to be stored accessible to thecertificate manager. Servers 53 a and 53 b may have installed thereonagents for access by the certificate manager 70, or services alreadyinstalled may be utilized to provide the necessary access by certificatemanager 70, for example the SSH service. The certificate manager mayalso include root certificates, whereby the certificate manager becomesa certificate authority that not only can issue and verify endcertificates, but can also maintain those end certificates automaticallyfor customers. The certificate manager may also include intermediateroot certificates, if the operator does is not or does not wish tooperate as a trusted authority.

An exemplary certificate management computer system is packaged in arack-mountable form-factor and includes a Pentium 4 processor operatingat 1.7 GHz or higher, 512 MB of 400 MFz SD-RAM, a RAID system includingtwo 40 GB hard drives in a data mirroring configuration, redundant powersupplies, two redundant 10/100 Base TX network ports, two 9-pin serialports, one parallel port, four USB ports, and a graphics port supportingVGA video modes and higher. Other computer systems may be utilized invarious circumstances, for example if a relatively small number ofcertificates are to be managed or if network access is provided througha non-Ethemet connection. Likewise, the computer system may have othersoftware installed thereon, provided that sufficient processing powerand network resources are provided to handle the total operating loadson the system.

The exemplary certificate manager includes a user interface accessiblethrough the HTTPS protocol, of which FIGS. 15 to 48 are representative.That user interface will now be described.

Referring first to FIG. 37, an administrator is provided access to theexemplary certificate manager by way of a web browser optionally locatedto a client computer. Upon first accessing the manager, the user isfirst directed to enter a username and password, or present acertificate or other token. Upon authentication by the manager, the websession of access is attributed to a user with optionally assignedaccess privileges. An authenticated user may be first directed to a homepage or a screen containing alerts directed to the user or the user'sgroup.

FIG. 15 is representative of a home page providing a number of links toother screens of various functions available through the exemplarycertificate manager. In that page, as well as others, the user ispresented with status information concerning the number of certificatesin process and critical alerts important for the user to view, appearingin a prominent location. Certificates in process and critical alerts towhich a user is not privileged to manage need not be indicated. Theexemplary home page provides activity groupings which include managingcertificates, network discovery, reports and logs. The availablemanagement activities shown include managing certificates, managingservers, managing groups, managing users, and system configuration.Network discovery activities include the discovery of servers andcertificates in the network. Activities related to reports include thegeneration and viewing of reports and reports concerning the history ofintermediate root certificates managed by the exemplary certificatemanager. Logs concerning general errors, critical alerts, and useractivity are also made viewable by links in the home page. Alsodisplayed on the home page may be statistics concerning the number ofcertificates and servers being managed, which may be indicative of thecertificates and servers managed by the particular user or thecertificate manager generally. In this screen, as well as others,shortcuts may also be provided to direct the user to frequentedactivities, for example manage certificates and manage servers.

FIG. 16 depicts a representation of a manage certificates screen, asmight be displayed by transversal through the home page. That screenincludes a list element through with the list of managed certificatesmay be displayed, the certificates managed by a certificateidentification including a numeric certificate ID and a common name. Foreach certificate selectable objects are provided to view, edit, removeand show the history of each individual certificate. The list is furtherfilterable by a textual or numeric criteria, bypassing extensivepage-after-page displays of certificates if the number of managedcertificates is large. Also in that screen an “add certificate” buttonis provided to add a certificate to the managed certificate database.

FIG. 40 shows a representative screen of a view of certificateinformation, FIG. 47 shows a screen whereby an administrator may enterinformation about a new certificate, while FIG. 42 depicts a screen inwhich an existing certificate record may be edited. In those views anadministrator may be presented with various elements of particularcertificates tracked in a certificate database, which in the exemplarycertificate manager are: Field name Contents Common Name: Specifies thefully qualified hostname used in DNS lookups (for example,www.imcentric.com). This is the hostname in the URL that a browser usesto connect to the server on which the certificate is located. It isimportant that these two names are the same. Otherwise, a client maynotice that the certificate name does not match the site name, whichoften makes users doubt the authenticity of the certificate.Organization Name: Specifies the official, legal name of the company,educational institution, or other organization owning the certificate.Organization Unit: Specifies a description of an organizational unitwithin the organization. Contact: Specifies an individual who isresponsible for this certificate. City: Specifies a description of thecity, principality, or country for the organization. State: Specifiesthe state or province in which the business is located. Country:Specifies the two-character abbreviation of the country name (in ISOformat) of the business location. Valid From: Specifies the effectivedate of the certificate. Valid To: Specifies the expiration date of thecertificate. Certificate Strength: Specifies the bit strength of thekeys of the certificate. Renewing Certificate Authority: Specifies theCA through which the certificate is to be renewed. Server: Specifies theserver on which the certificate is or will be installed. Secure ServerName: Specifies the instance or name of the web server where thecertificate is or will be used.

FIG. 17 shows a representation of a manage servers screen, again asmight be displayed from the home page. That screen includes a list ofmanaged servers listed by a server ID, a hostname and an IP address. Foreach server shown in the list selectable objects are provided to view,edit, remove and show the history of each server. This list is alsofilterable, the filter operating by textual or numeric fragments of theserver ID, hostname, or IP address. An “add server” button is alsoprovided to add server information for a new server to be managed.

If an administrator selects to view or edit a server record, a screensimilar to that of FIG. 46 appears. In that screen, the server columndata of the particular record appears, which columns may include: Fieldname Contents Host Name Specifies the hostname of the server. IP AddressIP Address of the server. Description Description of server. Port Portused to access the server, some common ports are ssh(22), telnet(23), orweb(8888). Username Username used to access server. Is SSL EnabledSpecifies if the admin pages are accessed via SSL. (Note: only used onNetscape 3.6 and Iplanet.)

In the exemplary certificate manager users may be grouped together toease the administration of user privileges. FIG. 18 shows a samplescreen for managing groups in the exemplary certificate manager. As withmanaged certificates and servers, the recorded groups appear in a listfrom which a group may be viewed, edited, removed or historicallyviewed. Groups appear in the list as a group ID and a group name. Groupsmay be added by selecting the “add group” button. Depicted in FIG. 42 isa screen for editing a group. In that screen the group name appears in atextbox, which may be modifiable therein to rename the group. The memberusers of the group appear in a list including sufficient identificationto discriminate users, in this example the user ID, first and last name,email address, and role assignment for the user. User members may beadded to a group by clicking the “add member” button, which brings up aseparate screen depicted in FIG. 48 whereby registered users may beselected for inclusion in a group.

In FIG. 19 a representative screen is depicted for the management ofregistered users in the exemplary certificate management system. Theregistered users are presented in a list, with selectable objects forviewing or editing user information, removing a user, and reviewing ahistory of user actions. Each user is referenced by a first and lastname, and email address, and a username. A button is provided for addinga new user to be added to the registered user list.

Depicted in FIG. 38 is a representative screen for viewing the entriesof a particular user registered in the system. FIG. 39 shows a similarscreen for editing the entries of a user. In the exemplary certificatemanager a default set of fields are included in the user database, whichare outlined in the following table: Field name Contents First NameFirst name of the user. Last Name Last name of the user. Title PositionTitle for the user. Company Company with which the user is employed.Department The user's department in the company. Address Street address(home or office) for user. City City in which the address is located.Zip Postal code for the city. Email Email address for user. Work PhoneWork phone number for user. State State in which the city is located.Country Country in which the state is located. Fax Number Fax number foruser. Username The identifier index of the user. Password The passwordof the user (may be hashed).

Additionally included in the screens shown in FIGS. 38 and 39 is anactive directory input facility, by which an administrator may importuser information by providing an import path and the username andpassword of access for the directory service.

FIG. 20 depicts a representative screen of the exemplary certificatemanager whereby network settings may be input. The network settingsinclude the IP address, subnet, and gateway of the manager. DHCP mayalternately be enabled by checking the appropriate checkbox, whichoverrides the 'P address, subnet and gateway settings. The exemplarymanager may be configured to require a specified client certificate bepresent at clients accessing the administrator user interface, whichfunction may be enabled by selecting the appropriate checkbox. Now themanager device may also provide for issuance or renewal of certificatesby HTTP scripts controlling provided certificate authority userinterfaces, as described above. The manager device includesconfiguration for use of an optional proxy server, including address,port, username and password, which may be useful if the manager deviceis located behind a firewall restricting default HTMP traffic. Thescreen of FIG. 20 further includes a location to enter an email addressfor transmitting critical alerts to a selected email box, if desired.

In FIG. 21 a representative screen is depicted containing entries forcustom fields for managed certificates. The exemplary certificatemanagement system may track with certificates other information, such asaccounting codes, use notations or other custom information that may notbe required or suggested by a certificate standard or a certificateauthority. By checking the “required” checkbox for the field, selectedfields may be made to be required, by which the manager will force theentry of a user to the field at the time a certificate is created by thesystem. By checking the “X.509” field for the field, that field will beincluded in the content of the certificate, otherwise the system willtrack the information of the field separately.

FIG. 22 depicts a representative screen by which the certificatedatabase settings may be maintained. In the exemplary system, thecertificate database may be backed up to a file on a network drive,which directory may be specified in the “path to network share” entry.If a username and password are required to access that drive, it may beentered in this screen. The administrator may also specify a backupinterval, in this example of 7 days between backups. The exemplarycertificate manager creates backups of managed certificate and serverinformation, users, groups, and may also include copies of the managedcertificates in the backups as well.

FIG. 23 shows a representative screen by which default certificateinformation may be configured to the exemplary manager. The screen ofFIG. 23 is for a Windows 2003 Certificate Authority, which CA is usefulfor generating internal root and end certificates. Other screens areprovided by the exemplary certificate manager for configuring the serverto operate with other certificate authorities, for example Versign orEntrust, in various modes of operation. The exemplary manager may alsoinclude facilities for retrieval of connection information from a CAover the Intemet, if identification is provided in the configurationscreen for that CA. The certificate authority screen shown includesentries for a network path to the certificate authority, a username andpassword, domains managed. The value of the organization name field isincorporated into all certificate signing requests sent to theparticular certificate authority, unless overridden elsewhere.

The CA setup screens may be modifiable by program updates from theseller, manufacturer or licensor to adapt to changes in the operation ofthe certificate authorities made available for use. Those programupdates may also include updates to the scripts (or other programmableelements) used to interact with the certificate authorities intended tobe usable to the administrator.

A second exemplary certificate manager may be set up as a replicator fora first manager, providing failover functionality. Shown in FIG. 24 isan exemplary screen in which replicator settings may optionally beconfigured.

Depicted in FIG. 25 is a screen for entering network discovery settings.The exemplary certificate manager may perform discovery on a network tolocate servers and certificates that may need to be managed. Thediscovery settings include one or more IP address ranges to scan, and anumber of IP ports to scan. The manager may be configured to performdiscovery periodically to automatically detect newly installed serversand certificates. The automatic discovery interval may be set in the“scan interval” checkbox, and the time of day to perform the scan may beentered into the “beginning scan time” pulldowns. Discovery may also bedisabled by checking the “disable scan” checkbox.

The exemplary certificate manager may also manage intermediate rootcertificate authorities and intermediate certificate authorities, suchas might be the case with a Windows 2003 CA above. The configuration ofthe intermediate root certificate authority settings for the manager maybe controlled in a screen similar to that shown in FIG. 26. That managermay permit the maintenance, storage and access of intermediate rootcertificates by the manager, or may permit maintenance at a differentserver device. In the screen shown in FIG. 26 an intermediatecertificate to be managed may be entered in the textbox, followed by theadministrator clicking on “import”. The new intermediate certificate maythen be included in the maintained intermediate root certificates beingmanaged, and displayed in a list with others as desired.

The exemplary certificate manager may also scan for intermediatecertificates on the discovery network. The manager may discriminate anend certificate from an intermediate root certificate by a review ofcertificate contents, or the manager may examine the chain of authorityfor certificates for parents located on the discovery network.

FIG. 27 depicts a screen whereby the log archival settings may be set inthe exemplary certificate manager. In that manager, logs may be archivedremotely to prevent accumulation on the manager itself. This screenpermits the setting of a network location, time, interval, username andpassword for the error log and the history recorded by the manager.

FIG. 28 depicts a representative screen permitting the management ofcertificates discovered but not yet completed in the exemplary manager.A list of certificates is presented, with a discovery-assignedcertificate id and the common name recorded in each certificate. Foreach certificate, a complete and remove selection are provided. If anadministrator desires to complete the entry of a discovered certificateinto the database, he may click on complete. Likewise, if anadministrator decides that a discovered certificate need not be managed,he may click on remove (the removal is only for the manager database—thecertificate is not removed from a server). FIG. 29 depicts a similarscreen permitting the completion or removal of discovered server recordsto or from the database.

The exemplary certificate manager additionally permits the generation ofvarious reports. Depicted in FIG. 30 is a screen whereby a report may beselected from a list of available reports, generated and printed.Depicted in FIG. 35 is an exemplary view reporting all managedcertificates, detailing the name, status, validity dates, and othercertificate information. A similar report is depicted in FIG. 36, bywhich all managed servers are listed including details such as thehostname, IP address, port a certificate was accessible, the serversoftware platform, the operating system, the protocol used forconnecting to the server, as well as other related information. Anadditional report, not shown, lists the users registered with theexemplary manager.

Of the reports available, several historical reports may be generated bythe exemplary manager. Depicted in FIG. 31 is a historical report ofintermediate root certificate authority scans, including updates to thecurrent database entries. Shown in FIG. 43 is a report of user actionswithin the manager, each user action including a date, time, action,user and value among other potential action informational items. FIG. 44shows another history view, this one of changes to the certificatedatabase, each change record including the date and time of change, thecolumn changes, the new value, and the user making the change. FIG. 45shows a historical view of changes to the server database, each recordincluding the date, time, column, new value of the change and the usermaking the change.

The logs generated by the exemplary manager are also viewable. FIG. 32depicts a view of the error log, including a description of each errorand the time of occurrence. A list of error codes and meanings appearsin Appendix A for the exemplary certificate manager. FIG. 33 depicts aview of the alerts log, which in this view is empty. If, for example,renewal of a-certificate was unsuccessful, that event might appear inthis log view. Attempts to notify administrators may also appear in thealerts log. FIG. 34 depicts a view of the user log, which includes alist of user actions to the database as well as other actions.

Further in the exemplary manager, user roles may be assigned to users. Auser may thereby be given authorization to perform variousadministrative actions, for example authorizing the request of newcertificates or merely viewing the certificate database. The exemplarymanager may additionally act as a firewall to the management software,permitting communication only to selected ports in the network protocol.For example, a manager might enable port 443 for HTITS administrativeuser interface access and port 25 for receiving email in a TCP/IPprotocol supporting manager. Providing firewall functionality mayprevent attacks from worms, buffer overflow attacks or other attacks,and make a manager suitable to be connected directly to a public networksuch as the Internet.

The certificate database of the exemplary certificate manager mayadditionally be encrypted. Optionally, the manager may generate aself-signed certificate initially to encrypt the database. Theself-signed certificate may be protected from user access by userprivileges, by encryption with a fixed key, encoding in a non-readableor specialized format, or other method. Private keys used to generateCSRs are not stored on the exemplary manager, but are stored on thedestination servers (where they may have been generated by the creationof a CSR).

The exemplary manager may further include an updating tool. The updatingtool checks for security or bugfix updates to the system periodically,and downloads and installs any updates automatically. The manager mayfurther include one or more fail-safe mechanisms that run systemdiagnostics on a periodic basis to gauge the health of the system andattempt error recovery. Administrators may be notified by email if errorrecovery is unsuccessful. The manager may further include a databasebackup feature functional to restore and archive the state of thesystem.

Systems for Managing Digital Certificates to Client Devices

Systems described above permit the automatic maintenance of certificateson server devices of various types. Systems may also be constructed toinstall and maintain certificates on client devices as well. Referringnow to FIG. 13, an exemplary process is depicted permitting a serverdevice to authenticate a client component associated with a user,account, or other association. The client component might be, in severalexamples, a personal computer, a cell phone, a personal data assistant,or virtually any other client device operable by a person providingaccess to a service provider over a communications network. Thisprocedure begins in step 1302 by a request for connection, in thisexample by a client. The request for connection might also be initiatedby a server, in some circumstances. The server then requests anappropriate digital certificate from the client for authenticationpurposes. The client may present a certificate to the server if it isavailable. A client may, if desired, be configured to fetch acertificate from a CA if a proper certificate is not available.

If the client presents a certificate for authentication, tested in step1306, the server may proceed to validate the certificate as in step1308. The server may also test for certificate revocation, for exampleby comparing the certificate against a list of revoked certificates. Ifthe certificate has been revoked, or if the certificate is not valid forthe authentication purposes, tested in step 1310, the server may proceedto issue a new certificate to the client. Proceeding from one of steps1306 or 1310 to step 1312, the user is authenticated using an alternateprocedure, as a valid certificate was not presented. The alternateprocedure may take many forms, such as the entry of a known username andpassword, a passphrase, an account number and PIN number, or any otherprocedure which may identify the user of the device to the satisfactionof the service provider. Alternatively, if it is merely needed toidentify the client device upon subsequent accesses, the userauthentication need not be performed.

Upon successful alternate authentication, a new certificate is deliveredto the client. Under some circumstances it may be desirable to maintaina store of new certificates, to avoid delays in a service due to thetime required to issue a new certificate. Alternatively, a newcertificate may be created about the time of delivery, which might becreated by in internal or external certificate authority entity. Once anew certificate is delivered to a client, transactions may proceed withthe client device under an assurance of authentication, as in step 1320.

If in step 1308, the client certificate delivered to the server is foundto be valid and not revoked, a check for an expired certificate may beperformed in step 1316. If the certificate is not expired, authenticatedtransactions may proceed in step 1320. Otherwise, a process of renewinga certificate may commence, in step 1318. In that step, the oldcertificate is renewed with the appropriate certificate authority, whichmight be internal or external, and the renewed certificate delivered tothe client. The renewal of a certificate might occur at the time of theconnection attempt by the client, however a small delay may beintroduced, especially if an external certificate authority is used.Alternatively, a process may periodically run on the service side,checking issued certificates for expiration. Certificates may be renewedprior to a request for connection for services from a client, avoidingthe small delay, provided that the client certificates are stored in theservice system.

In the exemplary method described above, agents may be fashioned forparticular client devices. Through the method, an installed agent mayact to communicate with the service provider to receive certificatestherefrom. An agent may also, if desired, provide an interface forpresenting certificates to the service provider. An agent may alsoprovide for management of client certificates in a local store, if localclient facilities are not provided or not used otherwise. An agent may,if desired, remove managed certificates from a client device at the timethe agent is uninstalled. The agent might also be fashioned to be morecomprehensive in function, and may manage a session or transactions withthe service provider.

Agents may be fashioned for several kinds of client devices. Forexample, an agent might be fashioned as a background executable processor daemon communicating with a service provider on a selected TCP port,executables being provided for a number of operating system types suchas WinCE, PalmOS, PocketPC, Windows XP, MacOS, Linux, etc. In anotherexample, an agent might be downloaded from the service provider aboutthe time the request for connection for services is made. That agentmight be written in a platform-independent interpretive language, suchas Java, or might be an executable program provided by a server based onthe perceived client type. In that example, the agent might only resideon the client for a fixed period, although the client certificates mayreside at the client locally. In another example, the agent might be abrowser plugin, which may be automatically downloaded from a predefinedlocation at the time a user first attempts to access a service provider.In yet a further example, an operating system may provide accessservices sufficient to perform the agent functions, in which case theoperating system may be equivalent to a certificate agent.

As to a client certificate, a client may be identified in severaldifferent ways. In a first example, a client certificate contains anencrypted identifier assigned by the service provider, the encryptionperformed with a secret key known to the service provider but not byothers generally. The identifier may be associated with an individual'sservice, for example a bank account number or a user identifier for aninformation subscription service. The encrypted identifier might includea user identifier and a passphrase, for example a username and passwordor an account number and PIN number.

The identification data may not necessarily be kept secret. For example,if a service provider is in the business of providing access todatabases and literature for a fee, the impact of discovery ormonitoring the activities of the user might be negligible, although itmay be desirable for the service provider to ensure that the user issubscribed. In that example, a certificate might contain a subscriptionnumber digitally signed by a key maintained by the provider.

Now in the above client certificate management methods the serviceprovider may identify the individual or group using the service using apresumption that other individuals will not be permitted access to theclient device. For example, if the client device is a personal dataassistant (PDA), it may be presumed that that device is for a particularindividual only, which individual will retain control of to preventunauthorized use of the service provider's services. If that assumptionis made, a service provider may authenticate using a certificate on aclient device alone, and need not require the entry of passwords orother user authenticating items.

The service provider may also wish to prevent the transfer of acertificate from one client device to another. In that case, thecertificate may include information unique to the client device, forexample a MAC address, a fixed IP address, a serial number or aprocessor ID. The signature of the certificate may further be obtainedby encoding the unique information, causing a signature mismatch shouldthe certificate be moved. In an alternative system, an agent may providethe unique information to the service provider so as to avoid anunauthorized user masquerading a different client device for theoriginal device.

Referring now to FIG. 14, a system useful for managing clientcertificates and providing network services is depicted. A client 1400is connectable to an external network 1404 permitting connections with aservice provider device 1408, in this example through a router/gatewaydevice 1406. Service provider 1408 provides access to services through astandardized protocol, for example HTrPS. Client 1400 likewise includessoftware for communicating with service provider 1408 and forinteracting with the operator of client 1400, which might be a webbrowser supporting SSL if the service provider 1408 uses HTTIS. Acertificate store 1410 may be provided to store certificates issued ordeposited to clients, and may also store new and unissued certificates.Certificate store 1410 might be a shared certificate store, such as aMicrosoft Windows Certificate Store or Java Key Store, or in anotherexample might be a private certificate store managed by an agent. Arepository of revoked certificates 1412 may be consulted by serviceprovider 1408 to verify a client certificate presented by a client hasnot been revoked.

An agent server 1414 may also be provided to assist with the downloadand installation of agents to clients. An internal certificate authority1416 may be provided to produce encryption/decryption keys or facilitiesfor digitally signing certificates. In one example, internal certificateauthority 1416 is in communicative proximity to service provider 1408 soas to avoid substantial delays in data processing. Optionally, anexternal certificate authority 1418 may be used, which may be operatedindependently of the entity operating the service provider 1408. If anexternal certificate authority is used, a certificate may be used tosign user transactions which are afterward publicly verifiable. Acertificate store 1402 is provided at client 1400 to store certificatesissued by the service provider, making them available in later accessesbetween client 1400 and service provider 1408.

Now it is to be understood that service provider 1408, optionalcertificate store 1410, revoked certificate database 1412, agent server1414 and internal certificate authority 1416 might be completelyseparate computing systems connected by a network. Alternatively,elements of those may be combined as desired on shared computingresources. In another example, not shown, each of service provider 1408,certificate store 1410, revoked certificate database, agent server 1414are elements residing on a single server or distributed servers, withinternal certificate authority 1416 being optionally included thereon.The operation of a system according to the principles set forth above isillustrated in FIGS. 49 through 63, and will be presently described.

In FIG. 49, a user has accessed a service provider's download area via aweb browser on a client device, and is presented with an informationscreen about an agent system to be downloaded, activated by a “downloadnow” link. Following activation, the user is presented with a screenshown in FIG. 50, which presents further information concerning the“secure client” software. Clicking on the “next” button, the usercontinues to a step 2 screen shown in FIG. 51, which presents a licensewhich the user may assent to. The user may then be directed to a step 3screen as shown in FIG. 52, which provides a download button to startthe agent download process. The installation of the agent to the clientdevice immediately follows the download, and the user is presented withthe step 4 screen shown in FIG. 53. The user is then ready to use the“secure client” product.

Referring now to FIG. 54, the user accesses a server providing thesecure client service, and is presented a screen containing entry fieldsfor identifying information, in this example an email address and apassphrase. Now it is to be understood that other kinds of identifyinginformation might be more suitable for other circumstances, and theparticular entry fields shown are merely for explanation. Followingentry of the identifying information the user may click the login buttonto proceed to the screen shown in FIG. 55. In FIG. 55 the user ispresented with a screen indicating that authentication is in progress.

FIG. 56 shows a screen which would be presented to a user if the userhad not registered the client device being used with the service. Thismay be discovered by the service by the absence of an appropriatedigital certificate accessible to the agent downloaded and installed tothe device as in FIGS. 49 through 53. In this case, the user ispresented with a button (or other input) to add the present device tothe list of trusted devices. If the user does so, the user is presentedwith a screen as shown in FIG. 57. The user is presented with a entryfield for a mnemonic identifier for the device (“device name”), which isin this example “office computer.” Also in the screen of FIG. 57, a listof registered devices is shown, which in this example indicates the userhas registered his work PC, a PDA and a laptop. Following entry of thedevice identifier, the user may click the next button. If the user doesthis, a screen similar to that in FIG. 58 may be shown, indicating thatprocessing is proceeding to register the device with the service. Theprocessing registering the device might include generating a newcertificate, or selecting a pre-generated certificate, and installingthe certificate to the client device. The process may also includeassociating the entered device identifier with the certificate, andotherwise maintaining the user's profile.

In the exemplary service, each client device may be assigned trustlevels, the selection of which is shown in FIG. 59. Trust levels permitthe user to select activities which are authorized for clients whichhave been registered. In this example, those activities include viewinga bank account balance, browsing a public web site, applying for acredit line, completing a load application, making a transfer tosavings, making a transfer to checking, closing an account, andtransferring funds over a certain amount. Following a user's selections,the finish button may be pressed to commit those selections. Also in theexemplary service, the trust level selections are not stored on clientdevices. Those selections are stored in a database managed by theservice, though alternatively the selections might be maintained in asecure third-party system as well.

Depicted in FIG. 60 is a screen which is representative of a user's homescreen in the exemplary service. Displayed on that screen is the user'sprofile, a list of registered device, and a number of links forperforming several management actions including edit the profileinformation, change the passphrase and a viewing of transaction reports.For each registered device, selections are provided for changing thetrust levels associated with that device and a selection for removal ofthe device. Depicted in FIG. 61 is a screen representative of atransaction report. In the exemplary service, for each transaction arecord is created including the date of the transaction, the providerinvolved in the transaction, the certificate authority providing thecertificate used to sign the transaction, and various details of theparticular transaction types.

Depicted in FIG. 62 is a screen representative of a screen provided inthe exemplary service for selecting trust levels, in this case of the“home pc” client device. In this screen, not only may the user selectthe trust levels for the client device, but the user may also selecttrust levels for particular providers. A pull-down list is provided inthis example to enter a user selection of a provider, the particulartrust levels for that provider and device being shown and selectablebelow. A done button, not shown, may commit the selections for storageto the service provider.

Depicted in FIG. 63 is a screen provided by the exemplary service forthe editing of user information, that information including a first,middle, and last name, an address, a home and work telephone number, andcredit card information. In the example the information is subdividedinto ratings sections, which are labeled bronze, silver and gold. Now auser is not required to enter information beyond the “bronze” level,which constitutes a minimal identification criteria for the serviceprovider. As a user provides more information, the user may be assignedto higher ratings categories, and become eligible for enhanced benefitsfrom the system. For example, a user may provide credit card informationto authorize purchases from merchants through the system. The user mayalso be further made eligible for sweepstakes, prizes, discounts orrebates at higher ratings.

In the exemplary client authorization system above may provide forauthentication of a user under the requirements that (1) the user isusing a device made trusted earlier and (2) for transactions consideredhighly sensitive, that a username and password or other higher form ofauthentication be used. In the exemplary system above, it may not benecessary for a user to manage digital certificates, enrollments ordigital signing dialogs, although the client system may provide for suchactivities for advanced use. Also in that system, a global certificatemay be provided by the system to various service providers to signonline transactions, or several certificates may be created and storedat the client for signing transactions for several service providers.The exemplary system may also require confirmation by return email toadd or remove a client device from the registration list. Additionally,an intruder must not only obtain a username and password to create afraudulent transaction, but must also perform his actions from one ofthe registered client devices. This makes fraudulent activity much moredifficult to accomplish than with present systems that rely only on ausername and password for user identification.

Now although examples above may have included servers utilizing SSL orTLS protocols, the examples above may be modified as will be understoodby those skilled in the art to encompass other protocols, such asmessage queuing systems, VPN systems, S/MIME systems, EPsec systems,code signatures, 802.11x EAP devices, encrypting file systems (EFS), andclient web authenticators, as well as other server types and protocols.Likewise, the above examples have referenced web servers utilizingdigital certificate. Those examples may also be modified to includeother server types such as application servers, databases, SSLoffloading devices, SSL accelerators, or any other type of server ordevice having the ability to utilize an SSL certificate to communicatesecurely over a network connection. The above examples have also madeuse of SSL certificates. Other types of certificates of varying formatsand protocols may also be used in the above disclosed systems with minormodification to operate with virtually any conceivable public keyinfrastructure.

While a number of digital certificate discovery and management systemshave been described and illustrated in conjunction with a number ofspecific configurations and methods, those skilled in the art willappreciate that variations and modifications may be made withoutdeparting from the principles herein illustrated, described, andclaimed. The present invention, as defined by the appended claims, maybe embodied in other specific forms without departing from its spirit oressential characteristics. The configurations described herein are to beconsidered in all respects as only illustrative, and not restrictive.All changes which come within the meaning and range of equivalency ofthe claims are to be embraced within their scope.

Appendix A

The following is a list of possible error codes, descriptions, andsuggested resolutions. ERROR CODE DESCRIPTION 0 Success 100 No resultsfound for the given query 101 Could not insert row into table 102 Couldnot update the information in the table 103 The database query hasfailed 1200 Specified service was not found 1201 User is not authorizedfor this service 1202 Service file was not found 1203 Service is notactive 3000 Failed to retrieve certificates 3001 Failed to processcertificate 3002 Failed to post a CSR to the web site 3003 Failedapproving certificate renewal on web site 4000 Could not find the firstsearch string of the common name 4001 Could not find the second searchstring of the common name 4002 Could not find the first search string ofthe certificate 4003 Could not find the second search string of thecertificate 4004 Could not find the common name 4005 Could not find thecertificate 4006 Certificate extraction failed 4007 Could not savecertificate. Check ID and common name 4008 Could not find\“C:\\Inetpub\\mailroot\\Drop\” folder 5000 Could not establish aconnection with the telnet server 6000 Could not create the CSR for thisplatform 6001 Could not install the Certification on the platform 6500Exception in Create Csr 6501 Invalid initial login password 6502 Invalidpassword config 6503 Could not find the config-ssl prompt 6504 Sonicwallalready in use elsewhere - could not connect to configure ssl interface6505 Could not find the config-ssl-server prompt 6527 Exception inInstall Certificate 6528 Invalid initial login password 6529 Invalidpassword config 6530 Could not find the config-ssl prompt 6531 Sonicwallalready in use elsewhere - could not connect to configure ssl interface6600 IPlanet Install Certificate: Document Complete Never Fired 6601IPlanet Install Certificate: Invalid username or password 6602 IPlanetInstall Certificate: Invalid certificate text 6603 IPlanet InstallCertificate: Missing certificate text (the text was empty) 6604 IPlanetInstall Certificate: Missing the key pair database password (thepassword was empty) 6605 IPlanet Install Certificate: Invalid key pairdatabase password 6606 IPlanet Install Certificate: Could not find theKey Pair Password field on the HTML page 6607 IPlanet InstallCertificate: Could not find the MessageText radio button on the HTMLpage 6608 IPlanet Install Certificate: Could not find the MessageTexttext area box on the HTML page 6609 IPlanet Install Certificate: Couldnot find the OK button to install the certificate on the HTML page 6610IPlanet Install Certificate: Could not find the Replace button toconfirm the install on the HTML page 6611 IPlanet Install Certificate:Could not find the Server On button to restart the server 6612 IPlanetInstall Certificate: The automation did not occur or was not completedsuccessfully. (m_bIsFinished was already true) 6613 IPlanet InstallCertificate: Could not find the Add Server Certificate Button 6614IPlanet Install Certificate: Alias value not found in select box 6615IPlanet Install Certificate: Navigation to admin page failed. Possibleheavy internet traffic or no network connection. 6616 IPlanet InstallCertificate: Navigation to install certificate page failed. Possibleheavy internet traffic or no network connection. 6617 IPlanet InstallCertificate: Server user name blank 6618 IPlanet Install Certificate:Server password blank 6619 IPlanet Install Certificate: IP address blank6620 IPlanet Install Certificate: Secure server name blank 6621 IPlanetInstall Certificate: Key pair password blank 6622 IPlanet InstallCertificate: Certificate text blank 6623 IPlanet Install Certificate:Navigation to confirmation page failed. Possible heavy internet trafficor no network connection. 6624 IPlanet Install Certificate: Replacecertificate confirmation window not found 6625 IPlanet InstallCertificate: Add certificate confirmation window not found 6626 IPlanetInstall Certificate: Alias blank 6090 Verisign Retrieve Organization:Navigation to main page failed. Possible heavy internet traffic or nonetwork connection. 6091 Verisign Retrieve Organization: Errorretrieving data collection of organization information 6100 VerisignPost CSR: Document Complete never fired 6101 Verisign Post CSR:Automation did not complete (m_bIsFinished == true) 6102 Verisign PostCSR: Missing the First Name parameter 6103 Verisign Post CSR: Aduplicate CSR was posted to Verisign's site which cannot be issued 6104Verisign Post CSR: Missing the Last name parameter 6105 Verisign PostCSR: Invalid email format, must be in format user@mail.com 6106 VerisignPost CSR: Missing Challenge Phrase 6107 Verisign Post CSR: Missing theOrganization Name 6108 Verisign Post CSR: Invalid Organization Name 6109Verisign Post CSR: Invalid CSR Text or missing CSR Text Fields 6110Verisign Post CSR: Verisign MPKI URL blank 6111 Verisign Post CSR: FirstName blank 6112 Verisign Post CSR: Last Name blank 6113 Verisign PostCSR: Contact email blank 6114 Verisign Post CSR: Challenge phrase blank6115 Verisign Post CSR: Missing CSR text 6116 Verisign Post CSR:Additional Fields data table NULL 6117 Verisign Post CSR: Navigation topost CSR page has failed. Possible heavy internet traffic or no networkconnection. 6118 Verisign Post CSR: Could not find text field for CSRtext 6119 Verisign Post CSR: Could not find text field for First Name6120 Verisign Post CSR: Could not find text field for Last Name 6121Verisign Post CSR: Could not find text field for Email address 6122Verisign Post CSR: Could not find text field for Challenge Phrase 6123Verisign Post CSR: Could not find text field for Challenge Phraseconfirm 6124 Verisign Post CSR: Could not find drop down box forApplication Server Type 6125 Verisign Post CSR: Your challenge phraseand reconfirmation do not match. 6126 Verisign Post CSR: Please enter avalid IP Address. 6127 Verisign Post CSR: Error finding additionalfields 6128 Verisign Post CSR: Navigation to CSR Result page failed.Possible heavy internet traffic or no network connection. 6129 VerisignPost CSR: Could not find additional fields 6130 Verisign Post CSR: Oneor more additional fields has invalid data. The information enteredshould contain only alphabetical or numerical characters . . . 6131Verisign Post CSR: Unable to start up and connect a browser instance.6132 Verisign Post CSR: Unable to Navigate the browser. 6133 VerisignPost CSR: An error occurred while checking for ‘First Name’ errormessage. 6134 Verisign Post CSR: An error occurred while checking for‘Last Name’ error message. 6135 Verisign Post CSR: An error occurredwhile checking for an invalid email format error message. 6136 VerisignPost CSR: An error occurred while checking for the Challenge Phraseerror message. 6137 Verisign Post CSR: An error occurred while checkingfor the company name error message. 6138 Verisign Post CSR: An erroroccurred while checking for an invalid Organization Name error message.6139 Verisign Post CSR: An error occurred while checking for Invalid CSRText error message. 6140 Verisign Post CSR: An error occurred whilechecking for duplicate cert error message. 6141 Verisign Post CSR: Anerror occurred while checking to see if the Enrollment of the CSR Textwas complete. 6142 Verisign Post CSR: An unknown error occurred whileposting the CSR Text. Unable to confirm if Enrollment was complete. 6143Verisign Post CSR: Invalid CA type passed to Postcard 6650 EntrustRetrieve Domains: The automation did not occur or was not completedsuccessfully. 6651 Entrust Retrieve Domains: Document Complete NeverFired 6652 Entrust Retrieve Domains: Username/ID box not found on loginpage 6653 Entrust Retrieve Domains: Password field not found on loginpage 6654 Entrust Retrieve Domains: Login button not found on login page6655 Entrust Retrieve Domains: Username or password not valid 6656Entrust Retrieve Domains: Less than two select boxes were found oncontract information page. 6657 Entrust Retrieve Domains: More than twoselect boxes were found on contract information page. 6658 EntrustRetrieve Domains: Could not find the Domain Information select box. 6659Entrust Retrieve Domains: The User Id passed to Entrust Retrieve Domainswas blank 6660 Entrust Retrieve Domains: The Password passed to EntrustRetrieve Domains was blank 6661 Entrust Retrieve Domains: Could notcomplete navigation to Logon page 6662 Entrust Retrieve Domains: Couldnot complete navigation to Management page 6663 Entrust RetrieveDomains: Could not complete navigation to Contract Information page 6675Entrust Retrieve Organization Names: The automation did not occur or wasnot completed successfully. 6676 Entrust Retrieve Organization Names:Document Complete Never Fired 6677 Entrust Retrieve Organization Names:Username/ID box not found on login page 6678 Entrust RetrieveOrganization Names: Password field not found on login page 6679 EntrustRetrieve Organization Names: Login button not found on login page 6680Entrust Retrieve Organization Names: Username or password not valid 6681Entrust Retrieve Organization Names: Less than two select boxes werefound on contract information page. 6682 Entrust Retrieve OrganizationNames: More than two select boxes were found on contract informationpage. 6683 Entrust Retrieve Organization Names: Could not find theOrganization Name select box 6684 Entrust Retrieve Organization Names:The User Id passed to Entrust Retrieve Organization Names was blank 6685Entrust Retrieve Organization Names: The Password passed to EntrustRetrieve Organization Names was blank 6686 Entrust Retrieve OrganizationNames: Could not complete navigation to Logon page 6689 Entrust RetrieveOrganization Names: Could not complete navigation to Management page6690 Entrust Retrieve Organization Names: Could not complete navigationto Contract Information page 6700 IPlanet Create CSR: Document CompleteNever Fired 6701 IPlanet Create CSR: Could not find the CA Email Addressfield on the main HTML page 6702 IPlanet Create CSR: Could not find theKey Pair database field on the main HTML page 6703 IPlanet Create CSR:Could not find the Requestor Name field on the main HTML page 6704IPlanet Create CSR: Could not find the Telephone Number field on themain HTML page 6705 IPlanet Create CSR: Could not find the Common Namefield on the main HTML page 6706 IPlanet Create CSR: Could not find theEmail Address field on the main HTML page 6707 IPlanet Create CSR: Couldnot find the Organization field on the main HTML page 6708 IPlanetCreate CSR: Could not find the Organization Unit field on the main HTMLpage 6709 IPlanet Create CSR: Could not find the Locality field on themain HTML page 6710 IPlanet Create CSR: Could not find the State orProvince field on the main HTML page 6711 IPlanet Create CSR: Could notfind the Country field on the main HTML page 6712 IPlanet Create CSR:Could not find the OK button on the main HTML page 6713 IPlanet CreateCSR: Invalid UserName or Password 6714 IPlanet Create CSR: Missing theCA Email Address (the text was empty) 6715 IPlanet Create CSR: Missingthe Key Pair Database Password (the text was empty) 6716 IPlanet CreateCSR: Invalid Key Pair Database Password 6717 IPlanet Create CSR: Missingthe Requestor Name (the text was empty) 6718 IPlanet Create CSR: Missingthe Telephone Number (the text was empty) 6719 IPlanet Create CSR:Missing the Common name (the text was empty) 6720 IPlanet Create CSR:Missing the Email Address (the text was empty) 6721 IPlanet Create CSR:Missing the Organization Name (the text was empty) 6722 IPlanet CreateCSR: Missing the Country (the text was empty) 6723 IPlanet Create CSR:Invalid Country (only a single letter was entered - must be two letters)6724 IPlanet Create CSR: The automation did not occur or was notcompleted successfully. (m_bIsFinished was already true) 6725 IPlanetCreate CSR: Invalid Country Code. 6726 IPlanet Create CSR: Alias valuenot found in select box 6727 IPlanet Create CSR: Trust database has notbeen initialized 6728 IPlanet Create CSR: User name blank 6729 IPlanetCreate CSR: Password blank 6730 IPlanet Create CSR: IP Address blank6731 IPlanet Create CSR: Secure server name blank 6732 IPlanet CreateCSR: Common name blank 6733 IPlanet Create CSR: Organization name blank6734 IPlanet Create CSR: Organization unit blank 6735 IPlanet CreateCSR: City blank 6736 IPlanet Create CSR: State blank 6737 IPlanet CreateCSR: Country blank 6738 IPlanet Create CSR: Contact email blank 6739IPlanet Create CSR: Contact first name blank 6740 IPlanet Create CSR:Contact last name blank 6741 IPlanet Create CSR: Contact work phonenumber blank 6742 IPlanet Create CSR: Key pair password blank 6743IPlanet Create CSR: Navigation to admin page failed. Possible heavyinternet traffic or no network connection. 6744 IPlanet Create CSR:Invalid secure server name 6745 IPlanet Create CSR: Navigation to createCSR page failed. Possible heavy internet traffic or no networkconnection. 6746 IPlanet Create CSR: Navigation to CSR page failed.Possible heavy internet traffic or no network connection. 6747 IPlanetCreate CSR: Error retrieving CSR 6748 IPlanet Create CSR: Invalid lengthfor the common name 6749 IPlanet Create CSR: Alias blank 6750 IPlanetCreate CSR: Could not find alias field 6751 IPlanet Create CSR: Couldnot find alias value 6760 Entrust Verify Login: The automation did notoccur or was not completed successfully. (m_bIsFinished was alreadytrue) 6761 Entrust Verify Login: Document Complete Never Fired 6762Entrust Verify Login: Username/ID box not found on login page 6763Entrust Verify Login: Password field not found on login page 6764Entrust Verify Login: Login button not found on login page 6765 EntrustVerify Login: Username or password not valid 6766 Entrust Verify Login:The User Id passed to Entrust Verify Login was blank 6767 Entrust VerifyLogin: The Password passed to Entrust Verify Login was blank 6768Entrust Verify Login: Could not complete navigation to Logon page 6769Entrust Verify Login: Could not complete navigation to Management page6775 Verisign Approve: Document Complete Never Fired 6776 VerisignApprove: Could not find the Process Requests link on the main HTML page6777 Verisign Approve: Could not find the Continue button on the HTMLpage 6778 Verisign Approve: The automation did not occur or was notcompleted successfully. (m_bIsFinished was already true) 6779 VerisignApprove: Common name was not found 6780 Verisign Approve: Approve linkwas not found 6781 Verisign Approve: Could not complete navigation tomain MPKI page. Possible heavy internet traffic or no networkconnection. 6782 Verisign Approve: Could not complete navigation toProcess Requests (approval) page. Possible heavy internet traffic or nonetwork connection. 6783 Verisign Approve: Could not complete navigationto approval result page. Possible heavy internet traffic or no networkconnection. 6784 Verisign Approve: Could not complete navigation to nextapproval page. Possible heavy internet traffic or no network connection.6785 Verisign Retrieve Organization Names: Could not find theorganization names ‘Org:’ label 6786 Verisign Retrieve OrganizationNames: Document complete did not fire 6787 Verisign RetrieveOrganization Names: Error occurred during retrieval of names fromelements on page 6788 Verisign Retrieve Organization Names: Could notcomplete navigation to Verisign's main MPKI page. Possible heavyinternet traffic or no network connection. 6790 Verisign retrieveorganization names: Unable to start up and connect a browser instance.6791 Verisign retrieve organization names: Unable to Navigate thebrowser. 6792 Verisign retrieve organization names: An error occurredwhile searching for the OrgName label. 6800 Autocert Utilities Service:Verisign certificate is neither a standard nor global certificate. 6801Autocert Utilities Service: Unable to update the standard mpki url tothe Certificate Authority table. 6802 Autocert Utilities Service: Unableto update the global mpki url to the Certificate Authority table. 6803Autocert Utilities Service: Unable to delete the domain name from thedomain verification table. 6804 Autocert Utilities Service: Unable toinsert the domain name to the domain verification table. 6805 AutocertUtilities Service: Unable to delete the organization name from theorganization verification table. 6806 Autocert Utilities Service: Unableto insert the organization name to the organization verification table.6807 Autocert Utilities Service: Initialization of WinINet functionsfailed. 6808 Autocert Utilities Service: Failed to establish sessionwith web site. 6809 Autocert Utilities Service: Failed to create Httprequest handle. 6810 Autocert Utilities Service: Failed to retrievecertificate from store. Verify certificate is installed. 6811 AutocertUtilities Service: Failed to attach certificate to http request. 6812Autocert Utilities Service: SPC system store failed to open. 6813Autocert Utilities Service: Failed to send request to server. 6814Autocert Utilities Service: Global certificate file not uploaded. Uploadcertificate before retrieving information. 6815 Autocert UtilitiesService: Standard server certificate file not uploaded. Uploadcertificate before retrieving information. 6816 Autocert UtilitiesService: Could not find Verisign standard account information. Verifycorrect certificate was uploaded. 6817 Autocert Utilities Service: Couldnot find Verisign global account information. Verify correct certificatewas uploaded. 6818 Entrust Post CSR: The User Id passed to Entrust PostCsr was blank. 6819 Entrust Post CSR: The Password passed to EntrustPost Csr was blank 6820 Entrust Post CSR: The Certificate Id passed toEntrust Post Csr was blank 6821 Entrust Post CSR: The Organization namepassed to Entrust Post Csr was blank 6822 Entrust Post CSR: The Csrpassed to Entrust Post Csr was blank 6823 Entrust Post CSR: The UserIDedit box on the login page could not be found. 6824 Entrust Post CSR:The Password edit box on the login page could not be found. 6825 EntrustPost CSR: The Log in button on the login page could not be found. 6826Entrust Post CSR: The Create/Renew button on the status page could notbe found. 6827 Entrust Post CSR: The Organization Name select box couldnot be found on the Create/Renue page. 6828 Entrust Post CSR: TheCertificate Type select box could not be found on the Create/Renue page.6829 Entrust Post CSR: The Standard option could not be found as aselection in the Certificate Type select box on the Crate/Renue page.6830 Entrust Post CSR: The Create Certificate button could not be foundon the Create/Renew page. 6831 Entrust Post CSR: The Certificate signingrequest text area could not be found on the Create/Renew page. 6832Entrust Post CSR: The Tracking information edit box could not be foundon the Create/Renew page. 6833 Entrust Post CSR: The Confirm button wasnot found on the confirmation page. 6834 Entrust Post CSR: The CSRprovided has already been posted, duplicate csr. 6835 Entrust Post CSR:The CSR does not begin with -----BEGIN (five dashes and BEGIN) which isrequired by Entrust. 6836 Entrust Post CSR: The CSR if for an invaliddomain. 6837 Entrust Post CSR: The CSR has an invalid country code. 6838Entrust Post CSR: The company is using all of its SSL ServerCertificates. 6850 Entrust Post CSR: Document Complete did not fire 6851Entrust Post CSR: could not complete automation. 6852 Entrust Post CSR:An invalid UserId or Password was used. 6853 Entrust Post CSR: Could notcomplete navigation to Logon page 6854 Entrust Post CSR: Could notcomplete navigation to certificate management page 6855 Entrust PostCSR: Could not complete navigation to post CSR page 6856 Entrust PostCSR: Could not complete navigation to post CSR confirmation page 6857Entrust Post CSR: Could not complete navigation to post CSR finishedpage 6858 Entrust Post CSR: Confirmation page not found 6859 EntrustPost CSR: Unable to navigate to Login Page 6861 Entrust Post CSR: Unableto Locate the Username Element in any of the Frames of the Web BrowserDocument. 6862 Entrust Post CSR: Unable to authenticate the login. Theusername and/or password are incorrect or refused by Entrust. 6863Entrust Post CSR: Unable to start up and connect a browser instance.6864 Entrust Post CSR: An error occurred while searching for the CSRheader sting in the Html text from the WebBrowser document. 6865 EntrustPost CSR: An error occurred while searching for the Tracking labelstring in the Html text from the WebBrowser document. 6866 Entrust PostCSR: An error occurred while checking if the CSR is a duplicate. 6875Entrust Post CSR: An error occurred while checking the CSR for fivedashes 6876 Entrust Post CSR: An error occurred while checking if allthe SSL Server Certs have been used for the login account. 6877 EntrustApprove Certificate: Document Complete Never Fired 6878 Entrust ApproveCertificate: The automation did not occur or was not completedsuccessfully. (m_bIsFinished was already true) 6879 Entrust ApproveCertificate: Username/ID box not found on login page 6880 EntrustApprove Certificate: Password field not found on login page 6881 EntrustApprove Certificate: Login button not found on login page 6882 EntrustApprove Certificate: Username or password not valid 6883 Entrust ApproveCertificate: Certificate was not found 6884 Entrust Approve Certificate:The User Id passed to Entrust Approve Certificate was blank 6885 EntrustApprove Certificate: The Password passed to Entrust Approve Certificatewas blank 6886 Entrust Approve Certificate: The Certificate Id passed toEntrust Approve Certificate was blank 6887 Entrust Approve Certificate:Could not complete navigation to Logon page 6888 Entrust ApproveCertificate: Could not complete navigation to certificate managementpage 6889 Entrust Approve Certificate: Could not find ‘Ready’ text inthe TR tag 6890 Entrust Approve Certificate: Could not find Entrustgenerated tracking id 6891 Entrust Approve Certificate: Could not findReady link with Entrust generated tracking id 6892 Entrust ApproveCertificate: Could not complete navigation to Csr Posting Finished page6900 Entrust Retrieve Certificate: Document Complete did not fire 6901Entrust Retrieve Certificate: Automation did not complete 6902 EntrustRetrieve Certificate: Could not find the Unique Id field on the EntrustLogin frame 6903 Entrust Retrieve Certificate: Could not find thePassword field on the Entrust Login frame 7000 Entrust RetrieveCertificate: Could not find the Log in button 7001 Entrust RetrieveCertificate: Invalid Entrust Username or Password 7002 Entrust RetrieveCertificate: Certificate id was not found 8000 Entrust RetrieveCertificate: Could not find the BEGIN CERTIFICATE or END CERTIFICATEidentifiers 8001 Entrust Retrieve Certificate: Could not find theCertificate page section identifier 8002 Entrust Retrieve Certificate:The User Id passed to Entrust Retrieve Certificate was blank 8010Entrust Retrieve Certificate: The Password passed to Entrust RetrieveCertificate was blank 9003 Entrust Retrieve Certificate: The CertificateId passed to Entrust Retrieve Certificate was blank 9011 EntrustRetrieve Certificate: Could not complete navigation to Logon page 9012Entrust Retrieve Certificate: Could not complete navigation toManagement page 9013 Entrust Retrieve Certificate: Could not find activetext 9014 Entrust Retrieve Certificate: Could not find tracking ID 9015Entrust Retrieve Certificate: Could not find active link 9016 EntrustRetrieve Certificate: Could not complete navigation to Finish page 9017IIS 6.0: Could not create the private key 9018 IIS 6.0: Could not createthe CSR 9019 IIS 6.0: Could not create the PFX 9020 IIS 6.0: Could notinstall the PFX 9021 AutocertMonitor: An exception occurred whilecalling the auto-update web service 9022 AutocertMonitor: Error loadinglocal xml manifest document 9023 AutocertMonitor: Error occurred duringLoadManifest call 9024 SMImport: Error connecting to csv file. Checkfile location. 9025 SMImport: Data type(s) incorrect in csv file. Checknumerical data. 9026 SMImport: Data format incorrect in csv file. Verifythat data in each field is correctly formatted. 9027 SMCertificate:Unable to update the Valid From and To dates in the Database 9028 ACLog:Could not get log configuration 9029 SMCertificate: Could not getcertificate 9030 SMCertificate: Could not get certificates by statuscode 9031 SMCertificate: Could not get and sort certificates by statuscode 9032 SMCertificate: Could not get certificates in renewal window9033 SMCertificate: Could not get all certificates 9034 SMCertificate:Could not get and sort all certificates 9035 SMCertificate: Could notget all certificates over max attempt number 9036 SMCertificate: Couldnot get and sort all certificates over max attempt number 9041SMCertificate: Could not get generated CSR data 9042 SMCertificate:Could not insert certificate 9043 SMCertificate: Could not updatecertificate 9044 SMCertificate: Could not update certificate edited bythe user 9045 SMCertificate: Could not update the certificate csr text9046 SMCertificate: Could not update the certificate active flag 9047SMCertificate: Could not update the certificate status code 9048SMCertificate: Could not update the certificate attempt count 9049SMCertificate: Could not update the certificate text 9050 SMCertificate:Could not update certificate private key text 9051 SMCertificate: Couldnot update certificate valid from/to date 9052 SMCertificate: Could notget certificate ID by common name 9053 SMCertificate: No certificategiven to split 9054 SMCertificate: Unable to retrieve all custom fieldtitles 9055 SMCertificate: Unable to get all custom fields 9056SMCertificate: Unable to read valid dates from certificate text 9061SMCertificate: Could not update the certificate CA tracking value 9062SMCertificate: Count not get certificates in process 9063SMCertificateAuthority: Could not get all certificate authorities 9064SMCertificateAuthority: Could not get certificate authority 9065EXCEPTION_SMCERTIFICATEAUTHORITY_GETCERTIFICATEAUTHORITYSETUPCOMPLETESORT 9066 SMCertificateAuthority: Could not updatecertificate authority setup complete 9067 SMCertificateAuthority: Couldnot update certificate authority username and password 9068SMCertificateAuthority: Could not update certificate authority post csrurl 9069 SMCertificateAuthority: Could not get any certificate authoritysetup complete 9071 SMCertificateAuthority: Could not get domainverifications by CA 9072 SMCertificateAuthority: Could not insert domainverification 9073 SMCertificateAuthority: Could not delete domainverification 9081 SMCertificateAuthority: Could not get organizationverifications by CA 9091 SMCertificateAuthority: Could not insertorganization verification 9092 SMCertificateAuthority: Could not deleteorganization verification 9093 SMCertificateAuthority: Could not getEntrust domain organization verification 9094 SMCertificateAuthority:Could not get semaphore error code 9095 SMCertificateAuthority: Couldnot update semaphore error code 9096 SMContact: Could not update contact9097 SMContact: Could not update contact active flag 9098 SMContact:Could not insert contact 9099 SMContact: Could not get all contacts 9101SMContact: Could not get and sort all contacts 9102 SMContact: Could notget contact 9103 SMContact: Could not get contact by certificate serialnumber 9104 SMContact: Could not get contact certificate serial number9105 SMContact: Could not verify user rights 9106 SMDatabase: Could notbackup database 9107 SMDatabase: Could not restore database 9108SMDatabase: Unable to get all status codes 9112 SMMailParse: Could notprocess mail 9113 SMServer: Could not get all servers 9114 SMServer:Could not get all server type codes 9115 SMServer: Could not get andsort all servers 9116 SMServer: Could not get server 9117 SMServer:Could not insert server 9118 SMServer: Could not update the serveractive flag 9121 SMServer: Could not update server 9122 SMServer: Couldnot get server type code by certificate ID 9123 SMServer: Could not getserver type code 9124 SMSettings: Could not get all settings 9125SMSettings: Could not get settings 9126 SMSettings: Could not updatesettings critical error email 9127 SMSettings: Could not update settingsdatabase backup path 9128 SMSettings: Could not update settings databaselast backup date 9129 SMSettings: Could not update settings databaselast backup path 9130 SMSettings: Could not update settings databasebackup interval 9131 SMSettings: Could not update settings proxy serveraddress 9132 SMSettings: Could not get settings critical error email9133 SMSettings: Could not get settings database backup path 9134SMSettings: Could not get settings max attempt number 9135 SMSettings:Could not get settings automation interval 9136 SMSettings: Could notget settings server email 9137 SMSettings: Could not get settingsdatabase backup interval 9231 SMSettings: Could not get settings proxyserver address 9232 ACCryptography: Could not install verisign admincertificate 9233 ACCryptography: Could not remove verisign admincertificate 9234 ACCryptography: Exception occurred while reading pfxfile 9235 ACCryptography: Not a valid pfx file 9141 ACCryptography:Incorrect password 9142 ACCryptography: Opening of pfx file failed 9143ACCryptography: ‘MY’ system store failed to open inInstallVerisignAdminCertificate 9144 ACCryptography: Import ofcertificate to ‘MY’ store failed 9145 ACCryptography: Empty parameterfor file path passed to InstallVerisignAdminCertificate 9146ACCryptography: Empty parameter for password passed toInstallVerisignAdminCertificate 9147 ACCryptography: ‘MY’ system storefailed to open in RemoveVerisignAdminCertificate 9148 ACCryptography:Failed to remove certificates from ‘MY’ store 9149 ACCryptography:Exception occurred while reading pfx file 9150 ACCryptography: Not avalid pfx file 9151 ACCryptography: Incorrect password 9152ACCryptography: Empty parameter for file path passed to VerifyPfxFile9160 ACCryptography: Empty parameter for password passed toVerifyPfxFile 9161 ACTelnet: Could not receive from server 9162ACTelnet: Could not send to server 9163 ACTelnet: Could not processoptions 9164 ACTelnet: Could not respond to options 9165 ACTelnet: Couldnot arrange reply 9166 AutoCertService: Exception in Main( ) 9167AutoCertService: Unable to get expiring certificates 9171AutoCertService: Unable to generate CSR 9172 AutoCertService: Unable topost CSR 9173 AutoCertService: Manual bulk approval failed 9174AutoCertService: Unable to approve certificates 9200 AutoCertService:Unable to retrieve certificates 9201 AutoCertService: Unable to splitcertificates 9202 AutoCertService: Unable to install certificates 9203AutoCertService: Unable to verify certificates 9204 AutoCertService:Unable to set proxy settings 9205 AutoCertService: Unable to set proxysettings 9206 Unable to connect to server while creating csr 9207Exiting create csr 9208 Unable to connect to server while installingcertificate 9209 Installation of certificate failed 9210 Unable toconnect to server while creating csr 9211 Exiting create csr 9212 Unableto connect to server while installing certificate 9213 Installation ofcertificate failed 9214 Access denied, Please check the username andpassword (for the Certificate Authority) and try again 9215 Unable toretrieve the certificate 9216 Unable to approve the certificate 9217Unable to post the CSR 9450 Common name exceeded maximum length 9451Domain name must be at the end of the common name 9501 ServerID notfound 9502 ContactID not found 9503 Server email not found 9511SMCertificateAuthority: Domain Name already exists in the database 9512SMCertificateAuthority: Organization Name already exists in the database9521 SMCertificate: No certificate given to split 9522 SMCertificate:Server certificate not found 9600 Verisign Global Setup: Error occurredwhile stopping service. 9601 Verisign Global Setup: Error occurred whilestarting service. 9602 Verisign Standard Setup: Error occurred whilestopping service. 9603 Verisign Standard Setup: Error occurred whilestarting service. 9604 Command prompt not received after terminal typeinput 9605 Command ‘genconf’ common name prompt not received 9606Command ‘genconf’ country name prompt not received 9607 Command‘genconf’ state prompt not received 9608 Command ‘genconf’ city promptnot received 9609 Command ‘genconf’ organization name prompt notreceived 9610 Command ‘genconf’ organizational unit prompt not received9611 Command ‘genconf’ Are these correct? prompt not received 9612Command ‘genconf’ command prompt not received 9613 Command ‘genkey’ keyfile already exists 9614 Command ‘genkey’ Are these correct? prompt notreceived 9615 Command ‘genkey’ country name prompt not received 9616Command ‘genkey’ state prompt not received 9617 Command ‘genkey’ cityprompt not received 9618 Command ‘genkey’ organization name prompt notreceived 9619 Command ‘genkey’ organizational unit prompt not received9620 Command ‘genkey’ common name prompt not received 9621 Command‘genkey’ second country name prompt not received 9622 Command ‘genkey’second state prompt not received 9623 Command ‘genkey’ second cityprompt not received 9624 Command ‘genkey’ second organization nameprompt not received 9625 Command ‘genkey’ second organizational unitprompt not received 9626 Command ‘genkey’ second common name prompt notreceived 9627 Command ‘genkey’ second hit return prompt not received9628 Command ‘genkey’ encrypt prompt not received 9629 Command ‘genkey’passphrase prompt not received 9630 Command ‘genkey’ verify passphraseprompt not received 9631 Command ‘genkey’ command prompt not receivedafter verify passphrase 9632 Command ‘cat’ command prompt not received9633 Command prompt not received after echo 9634 Command ‘genkey’ keyfile already exists 9635 Command ‘genkey’ Hit return prompt not received9636 Command ‘genkey’ command prompt not received 9637 Command ‘genkey’remove key prompt not received 9638 Command ‘genkey’ command prompt notreceived after key removed 9639 Command ‘genkey’ remove csr prompt notreceived 9640 Command ‘genkey’ command prompt not received after csrremove 9641 Command ‘genkey’ remove crt prompt not received 9642 Command‘genkey’ command prompt not received after crt remove 9643 Commandprompt not received after terminal type input 9644 Command ‘genconf’common name prompt not received 9645 Command ‘genconf’ country nameprompt not received 9646 Command ‘genconf’ state prompt not received9647 Command ‘genconf’ city prompt not received 9648 Command ‘genconf’organization name prompt not received 9649 Command ‘genconf’organizational unit prompt not received 9650 Command ‘genconf’ Are thesecorrect? prompt not received 9651 Command ‘genconf’ command prompt notreceived 9652 Command ‘genkey’ Hit return prompt not received 9653Command ‘genkey’ command prompt not received 9654 Command ‘genkey’remove key prompt not received 9655 Command ‘genkey’ command prompt notreceived after key removed 9656 Command ‘genkey’ remove csr prompt notreceived 9657 Command ‘genkey’ command prompt not received after csrremove 9658 Command ‘genkey’ remove crt prompt not received 9659 Command‘genkey’ command prompt not received after crt remove 9660 Command‘genkey’ key file already exists 9661 Command ‘genkey’ Are thesecorrect? prompt not received 9662 Command ‘genkey’ country name promptnot received 9663 Command ‘genkey’ state prompt not received 9664Command ‘genkey’ city prompt not received 9665 Command ‘genkey’organization name prompt not received 9666 Command ‘genkey’organizational unit prompt not received 9667 Command ‘genkey’ commonname prompt not received 9668 Command ‘genkey’ second country nameprompt not received 9669 Command ‘genkey’ second state prompt notreceived 9670 Command ‘genkey’ second city prompt not received 9671Command ‘genkey’ second organization name prompt not received 9672Command ‘genkey’ second organizational unit prompt not received 9673Command ‘genkey’ second common name prompt not received 9674 Command‘genkey’ second hit return prompt not received 9675 Command ‘genkey’encrypt prompt not received 9676 Command ‘genkey’ passphrase prompt notreceived 9700 Command ‘genkey’ verify passphrase prompt not received9701 Command ‘genkey’ command prompt not received after verifypassphrase 9702 Command ‘cat’ command prompt not received 9703 Commandprompt not received after echo 9704 Verisign Retrieve Domains: Unable tostart up and connect a browser instance. 9705 Verisign Retrieve Domains:Could not complete navigation to Verisign's MPKI main page 9776 VerisignRetrieve Domains: Error occurred during building of user services url9777 Verisign Retrieve Domains: Could not complete navigation to userservices page 9778 Verisign Retrieve Domains: Could not completenavigation to domains page 9779 Verisign Retrieve Domains: Erroroccurred during retrieving of domain names from page 9801 A timeoutoccurred while posting the csr, this may be due to network traffic orthe server may be down 9802 A timeout occurred while approving the csr,this may be due to network traffic or the server may be down 9803 Atimeout occurred while retrieving the certificate, this may be due tonetwork traffic or the server may be down 9804 Unable to start theWindows2003Ca Process this could be due to a misconfiguration in theWindows 2003 Certificate Authority setup, please check the settings tomake sure they are correct −1 ERROR UNKNOWN

1. A centralized certificate installation system for automating theinstallation of digital certificates received from certificateauthorities to a group of network servers, comprising: a processor; anetwork interface connectible to a data communications network, saidnetwork interface further controllable by said processor; a storagedevice group readable by said processor, said storage device groupcontaining at least one storage device operable to contain operatingsystem files and applications; instructions stored to said storagedevice group, said instructions being further executable by saidprocessor to achieve the functions of: (i) receiving a certificatesigned by a certificate authority generated from a certificate signingrequest by way of said network interface, (ii) identifying a destinationnetwork server corresponding to a received certificate signed by acertificate authority, (iii) determining a network server type, saidnetwork server types providing at least the type of server softwareinstalled to the identified destination network server, and (iv)performing a set of installation steps, the performed set ofinstallation steps applicable to the determined network server type, theperformance of the set of installation steps including the transferringof the received certificate to the destination network server by way ofsaid network interface.
 2. A system according to claim 1, wherein saidinstructions are further executable to achieve the functions of:operating an SMTP service; receiving an e-mail message by the SMTPservice, the e-mail message containing a certificate signed by acertificate authority; parsing an e-mail message containing acertificate signed by a certificate authority to extract thatcertificate for installation.
 3. A system according to claim 1, whereinsaid instructions are further executable to achieve the functions of:upon receiving a certificate signed by a certificate authority, andoptionally after identifying a destination network server, notifying aperson that the received certificate is ready to be installed; and priorto performing the set of installation steps, receiving an approvalindication from a person indicating that a certificate is to beinstalled.
 4. A system according to claim 1, wherein said performing aset of installation steps includes steps for automated controlling of anetwork interface provided by a web server.
 5. A system according toclaim 1, wherein said performing a set of installation steps includessteps for automated controlling of a shell interface.
 6. A systemaccording to claim 1, wherein said performing a set of installationsteps includes steps for transmission and installation of a certificatethrough a server agent program.
 7. A system according to claim 1,wherein said performing a set of installation steps includes steps forrestarting a destination server program.
 8. A system according to claim1, wherein said performing a set of installation steps includes stepsfor restarting a destination server computer.
 9. A system according toclaim 1, wherein said performing a set of installation steps includessteps for notifying an administrator to restart a destination serverprogram or destination server computer.
 10. A system according to claim1, wherein said instructions are further executable to confirm theinstallation of a received certificate to a destination server followingthe performance of a set of installation steps.
 11. A system accordingto claim 10, wherein said instructions are further executable togenerate an alert to an administrator if the installation of a receivedcertificate to a destination server is not confirmed.
 12. A centralizedcertificate installation system for automating the installation ofdigital certificates received from certificate authorities to a group ofnetwork servers, comprising: a processor; a network interfaceconnectible to a data communications network, said network interfacefurther controllable by said processor; a storage device group readableby said processor, said storage device group containing at least onestorage device operable to contain operating system files andapplications; authentication objects stored to said storage device, saidauthentication objects including authentication tokens needed to permitexecution of a set of certificate installation steps to servers of thegroup of network servers; instructions stored to said storage devicegroup, said instructions being further executable by said processor toachieve the functions of: (i) receiving a certificate signed by acertificate authority generated from a certificate signing request byway of said network interface, (ii) identifying a destination networkserver corresponding to a received certificate signed by a certificateauthority, (iii) determining a network server type, said network servertypes providing at least the type of server software installed to theidentified destination network server, said determining being performedby retrieving a server type from a database having an entry for theidentified destination network server; (iv) performing a set ofinstallation steps, the performed set of installation steps applicableto the determined network server type, the performance of the set ofinstallation steps utilizing said authentication objects applicable tothe destination network server, the performance of the set ofinstallation steps including the transferring of the receivedcertificate to the destination network server by way of said networkinterface; and (v) confirming the installation of a received certificateto a destination server following the performance of a set ofinstallation steps.
 13. A system according to claim 12, wherein saidinstructions are further executable to configure a destination networkserver to support SSL operation.
 14. A system according to claim 12,wherein said instructions are further executable to achieve thefunctions of: upon receiving a certificate signed by a certificateauthority, and optionally after identifying a destination networkserver, notifying a person that the received certificate is ready to beinstalled; and prior to performing the set of installation steps,receiving an approval indication from a person indicating that acertificate is to be installed.
 15. A system according to claim 12,wherein said performing a set of installation steps includes steps forautomated controlling of an interface selected from the group of networkinterfaces provided by a web server, a shell interface and server agentprogram interface.
 16. A system according to claim 12, wherein saidperforming a set of installation steps includes steps for restarting adestination server program or destination server computer.
 17. A systemaccording to claim 12, wherein said performing a set of installationsteps includes steps for notifying an administrator to restart adestination server program or destination server computer.
 18. A systemaccording to claim 12, wherein said instructions are further executableto confirm the installation of a received certificate to a destinationserver following the performance of a set of installation steps.
 19. Acentralized certificate installation system for automating theinstallation of digital certificates received from certificateauthorities to a group of network servers, comprising: a processor; anetwork interface connectible to a data communications network, saidnetwork interface further controllable by said processor; a storagedevice group readable by said processor, said storage device groupcontaining at least one storage device operable to contain operatingsystem files and applications; authentication objects stored to saidstorage device, said authentication objects including authenticationtokens needed to permit execution of a set of certificate installationsteps to servers of the group of network servers; instructions stored tosaid storage device group, said instructions being further executable bysaid processor to achieve the functions of: (i) receiving a certificatesigned by a certificate authority generated from a certificate signingrequest by way of said network interface, (ii) identifying a destinationnetwork server corresponding to a received certificate signed by acertificate authority, (iii) determining a network server type, saidnetwork server types providing at least the type of server softwareinstalled to the identified destination network server; (iv) performinga set of installation steps, the performed set of installation stepsapplicable to the determined network server type, the performance of theset of installation steps utilizing said authentication objectsapplicable to the destination network server, the performance of the setof installation steps including the transferring of the receivedcertificate to the destination network server by way of said networkinterface; the installation steps utilizing a protocol selected from thegroup of a shell interface, an agent interface and a network interfaceprovided by a web interface of a web server; (v) configuring anidentified destination managed server to use a private key correspondingto an installed certificate; and (vi) performing a restart actionselected from the group of commanding an identified destination managedserver to perform a restart, commanding an identified destinationmanaged server to restart and notifying an administrator to restart adestination server program or destination server computer; and (vii)confirming the installation of a received certificate to a destinationserver following the performance of a set of installation steps.